This project is read only...except it's not

I have a project that I have been working on now for months with no issues. After upgrading to Xojo 2022r4 last Friday, now when I open the project and attempt to make a change, I get a dialog box stating

This project is read only

The project is locked or on a read only volume. To make changes, please us "Save As..." and save it to a location where it can be read & written

I’ve never seen this before upgrading and, as a test, I tried opening and writing files to that same folder from Visual Studio, VS Code and Notepad++ and am able to open and write the files with no issue. It just seems to be Xojo that sees it as read only.

I’m running on Windows 10 Pro and saving to a mapped drive on my Windows 2016 server. I’ve verified that the folder/drive/share is RW and, as I said, can save and load fine from any other app.

Edit: I’ve tried this with three Xojo apps on that same share and all are showing as read only in Xojo but not other apps

Any ideas?

Is Xojo quarantined by chance? Nevermind, it can’t be you’re on Windows.

Though, this might be the problem:

Xojo doesn’t handle saving to servers very well. The general recommendation is to work locally and then copy to remote servers. My personal recommendation is to work locally and use a source control system instead of server-drive.

checked your windows defender messages for Folder Access blockings?

No messages in defender showing folder access blocking.

I understand that. I’ve been told that before, but recommending that it not be done shouldn’t preclude me from doing it. I’ve operated this way for 20 or so years, and do understand the risk. If Xojo had intrinsic Git support the way VS does this might actually be a valid option for me but as it is, I utilize my own backup strategy and having to copy the projects to and from the server every time I want to work on them isn’t something I’m willing to do.

1 Like

Sorry, but it seems you’ll have to find another way. Here’s the relevant ticket:

#56325 - Unable to use project on a network share (closed)

You’re not going to win this battle with Xojo. The problem is that network shares (especially SMB) are notoriously bad at reporting the locking state of files and folders and because the Xojo framework believes what the OS says and the Xojo IDE uses the Xojo framework, it gets the wrong information, and poof, it thinks your file is locked.

3 Likes

Do yourself a favor and install a source control system on the server.

Develop with a locally checked out working copy.

That’s more reliable in many ways…

6 Likes

I understand and, based on Xojo’s attitude in the past regarding issues that they don’t feel are issues, I know you’re right but it’s still a stupid and arrogant position for Xojo to take. This “we don’t think it’s the best way so we’re not going to fix it” attitude is the same crap that Microsoft and Apple have taken in the past few years. “We must protect the users from themselves”. I use several other development tools for other projects and none of them have this limitation.

Sorry for the rant. I’m just sick of companies not fixing their products because “it’s not a bug…it’s a safeguard”

Oh well.

2 Likes

It’s neither a feature or a safeguard. It is a fact that SMB shares report bad information on lock status. The operating system reports file as locked then nothing anyone can do can open that file. I’m not sure what you expect Xojo to do about that.

I’ve had Mac MS Word report similar issues on numerous occasions.

2 Likes

That reminds me I have experienced that in the past. It was in an “all Mac shop”. Their king-pin consultants instead of creating home directories on the server - used to run FileMaker Server - had the home directories on a Linux server. Once in a while, Word documents I created became suddenly Read-only :exploding_head:. The consultants spent many hours to fix the issue, but never really succeded.

Learning that SMB does not play well will MacOS makes my day !!!

Especially as they got rid of Apple sharing system in favour of SMB.

If you visit the SQLite website, you’ll see that they seriously dis-recommend keeping an SQLite database on a network machine, and serving it to a number of clients over the network. As has been mentioned here, the locking mechanisms of network file systems are not reliable, and there’s nothing Xojo (or even Apple/MS) can necessarily do about that. It’s actually even worse: cheaper disk drives will report to the OS that data has been written to the disk when, in fact, it has not. It’s only been received by the disk’s cache. They do this to give an apparent speed improvement.

1 Like

Amazed that SMB has this limitation (and is perceived so bad), while it’s the most used network protocol for sharing files. Either this should have been fixed for ages, or a better protocol should be available.

OK here’s a question: are these limitations inherent in SMB such that it would need a new version to be designed and then implemented, or are we suffering from poor implementations of a good protocol?

Whatever the answer is, we can’t fix it on our end.

1 Like

AppleShare (IP) was streets ahead in terms of reliability and capability. However, it was Mac only and there was no way MS were going to give up their server business.

Netware’s IPX protocol was also much better. We never had any problems from Mac or Windows.

SMB tries to be faster by using things like Opportunistic locking, which is just plain wrong.

1 Like

I agree and never use SQLite over a network as it is, in my opinion, designed to be a local database. That said, as Arnaud N mentioned, SMB an extremely widely-used protocol and, as I’ve said, in the 20+ years I’ve been using it for file transactions on my servers I have never come across a scenario where a file was suddenly locked.

Maybe I should just try using NFS. I use that for my VMware farms and most of my SAN/NAS connections (a few use iSCSI) and it’s always been rock-solid. Maybe Xojo would play nice with it.

I just wish they would acknowledge that this is an issue and at least try to fix it for those of us who (maybe foolishly) depend on it for day-to-day network services

1 Like

They have. Don’t do it.

It really is a fools errand. The behavior is different from platform to platform and exacerbated by a really slow encryption implementation. If your server is local, you can help yourself on macOS by turning off encryption and the faster response makes it marginally better (I do this at home for the speed boost, but not at work because it is a security risk).

If the server you’re connecting to does not require encryption, you can add an smb config file to turn it off:

  1. Mount the SMB share
  2. Using Terminal, check if encryption is on:

smbutil statshares -a

Look for SIGNING_SUPPORTED and SIGNING_ON.

  1. If they’re both set to “true” or “yes”

sudo nano /etc/nsmb.conf

  1. Enter the following text:
[default]
signing_required=no
  1. CTRL-X to exit
  2. Y to overwrite
  3. Unmount and remount any SMB shares.

You can undo this by editing that file again and removing those two lines. If you want this to only apply to a particular server, put the IP address or DNS name between the brackets.

Thanks Greg but, as stated in my original post, I’m on a Windows client not a Mac so I don’t think this is relevant in my case.