I am building a new app. I am copying items from another app (old app) to re-use in the new app. After I run the new app, then stop it, and then try to edit the new app, I get a message dialog that the app is read only. The message dialog has an OK button.
I click OK and the message dialog closes. As the message disappears I can see the window in the old app from where I copied a method or whatever, refresh.
I can then edit the new app, but the save button in the new app is not enabled after I make a change.
I can saveas and it appears to be saving but when I re-run the new app it does not have the changes I just made.
If I stop the program, I get the message again, and when I look at the code it reflects the changes, but they are not saved.
When I close the new app and then re-open the new app all of the changes are lost.
I have closed the old app and re-opened the new app only and the editing, running, stopping, and saving seems to be working normal again.
This was a problem appears to be similar to someone’s recent issue that was raised in one of the recent versions of Xojo… project changes did not get saved.
I can’t find the post that referenced it but I do recall seeing a back-and-forth about making it public as the OG post was in the Beta Testers group.
Same here, that is how I have always worked, for over 20 years, with all type of apps. So I hope that is not right. No issues like this until I did the update. My network drive is mapped as a drive letter. I don’t know why XOJO would care if it is actually a mapped drive.
It was an issue with the Arduino IDE for about a year and they finally got it fixed.
As an ex-Xojo engineer, I feel like I need to say that y’all have been extremely lucky saving your Xojo projects to network drives without ever experiencing corruption. Almost all of the unrecoverable projects that I have ever seen fall into this category.
It’s not a Xojo problem to fix. There is no way to know what sharing protocol is in use by the server, and to what degree it is implemented. SMB is a great example since its use is so widespread.
If you’re using windows 8/server 2012 or above for the server, you’re probably fine from a windows client. The best would be windows 10/server 2016 so you can use the most recent version of the 3.x protocol. Linux/macOS clients are tricky in my experience as they often claim to be compliant with a certain protocol version but then skimp on the hard things like encryption. Linux still uses Samba. macOS used samba until 10.7 and since then uses apples own implementation.
On the other hand, if you have a non-Microsoft server running some version of Samba or smbfs, without doing a deep dive, you’ll never know what’s really implemented or just implemented correctly. Take my Synology NAS for instance. It says it’s SMB 3.x compatible, but uses its own encryption scheme. That means that if your client supports SMB encryption, there’s a delay while connecting because you have to wait for the negotiation to fail or failover every time you connect.
In my experience, the biggest issue with networking surrounds locking. With the client/server protocol mismatches, you can often run into issues where a file is locked or unlocked on the server and the client can’t tell that state. In a perfect world, the SMB client says to your app “uh dude? That file you want to write to is locked” in reality, it just doesn’t know and it assumes everything is okay because writable is a bit and is considered on or off.
Oh, and network connections do drop from time to time. Sometimes in the middle of a transfer.
Like I said, I’m happy for you guys and I hope you never run into a problem. Just remember, this is kinda like smoking a cigarette when filling your gas tank. You may be lucky enough to never have a problem, but one day it might just explode in your face without warning.
Been there, done that, got the tee-shirt and learned my lesson.
Thanks Greg for your insights. I’ve been using iCloud for some of my programming and have not had any issues, yet. After reading this thread I’ve moved my programs to a local disk and then update the icloud version. This way I can access the programs from different computers and use iCloud for backing up.
I agree with Greg. I can see but two additional sources of unreliability for projects stored on a network drive compared to one stored locally.
a prolonged network link outage that exceeds the timeout limit
problems with locking, cause either by the application not doing it right, or by some driver or firmware component, locally or remote, that does not handle locking correctly
Note, that doing locking differently on a network drive vs. on a local drive is unreasonable. It is the job of the OS. BUT more than one app accessing the same file is much more likely on a network drive, as on a local, not shared drive on your personal workstation. Note, that many scenarios exist where shared access to a local file may cause problems also. in those cases, only the unreliability of the network link and network sharing are on top of the more general issues.
But back to the OPs issue. I don’t think it is related to issues with saving changes to the project file. All observations reported seem to point to the circumstance that Xojo did not consider the copied items to be part of the project to be saved. Is it possible, that the IDE’s internal representation of the project (used for saving) may get out of sync with the items shown in the project explorer (or whatever else it is called in the IDE)?
Greg,
In summary, I’m reading what you wrote as “NAS are not reliable to store data”.
So a NAS is just useless…
Wondering why there are guys who still make the mistake of buying them…
Feel free to tell me how your answer differs from how I read it.
Remember not everyone has an internal hard disk of, say, more than 1 TB (i.e. with enough space to store everything) nor codes on a single computer. Local drives may not be a choice.
I use my NAS every day. NAS is an acronym for Network Attached Storage after all. I use mine for storing all kinds of things, quite reliably I would add. I just don’t have applications other than the OS read or write to it.