A user of my app is having trouble saving a project file while Google Drive is synhcing it. So should I lock the file during its use to stop GD from synhcing? Is it common/standard/good practice for apps to lock the current project file while the app is open and then release it when the app closes or the file is closed? If so, what are the common pitfalls to watch out for and mitigate against? Should I do something like Word which creates a temp file? Thanks.
which is also what Xojo does too
Does anyone have any thoughts on this? Is it standard practice? What potential negative problems could it cause if any? Does anyone do this with their own apps? Thanks.
The locked property of a file is a user settable option, and thus should be respected as so. i.e. You shouldn’t mess with it.
Almost all online synchronizing services causes problems one way or another.
Are you using Atomic saving, if not you really should consider it. It’s where you write the data out to a temporary file first, then you replace the existing file with the temporary file. This way to don’t corrupt the original file in the even of a failure, and if GD is getting in the way, you’ve still written the users data to permanent storage.
You can use Autosave elsewhere, where you automatically write the users data to a temporary location at certain times, then when the user actually saves, then you replace their file. Although if I’m honest this can also cause issues, especially when the user is using a Syncing service as the data appears differently to the user, than it does on disk.
Thanks, Sam but I have a few follow-up questions…
So you’re saying that whatever I do it is bad practice to lock a user file while my app is using it?
I Googled but couldn’t find anything on Atomic saving. If you write to a temporary file, should that be right next to the original file or in a OS temp location? Also, even if you do that, surely at the point when you’re about to delete the original file and replace it with the temp file Google Drive could still be using the original file and so then the replace of file is blocked and the same issue arises? And then what happens? You have a temp file with latest data and original file locked by GD with old data. Would you then have to start a timer and constantly check for when the original file is accessible so the final replace/save can happen?
So I’ve been thinking about this; and I realize that I don’t actually have a solution for you. Below is basically thoughts about what I’ve run into.
The experience I have with DropBox, is that it resolves Symbolic Links, resulting in file duplication of macOS applications. iCloud is also weird, in that it alters standard file system functions from being synchronous to asynchronous, and sometimes will replace the file I’ve just modified with an older version (or not make my code believe that everything went okay, when in fact nothing actually happened). iCloud has this great feature also, in that if you disable it, it deletes the files from your computer.
I think the first step is to identify what exactly is going on. You can use the following to get the error code. When it fails.
IMHO, if Google are locking the file while they do their analysis on the file, this is bad practice, as Google is saying that they’re more important than the user, i.e. the User can’t change this file while Google is reading it. It should be the other way around, where the User has priority over Google.
But that doesn’t help solve the problem.
Traditionally with Atomic saving, you would save the temporary file right next to the original file, worse case scenario the user would see that there’s two files next to each other. However Apple’s modern “security” protocols prevent you from doing this (although certain Apple API will continue to operate this way; and yes I’ve been rejected from the Mac App Store several times because of this). So your safest bet is to use the dedicated Autosave Information folder in the Library folder.
Yes, you are correct in the sense that when you come to replace the file with the temporary file, it would still fail. At that point the politeest thing to do is to inform the user that their file cannot be written too, and offer to Save elsewhere (which you only need to move the saved file there).
IMHO the ideal solution to Autosave is autosave in place with save history. When your app Autosaves, it keeps the file up to date. When the user Saves, you store a copy of the current data (or enough meta data to be able to restore their data back to this point).
Thanks for your advice, Sam. Yes, it doesn’t seem like there’s a full-proof solution but from what you say it does appear that Google Drive is the one making the mistake by locking the file and I don’t think I should have to screw with my app and possibly create more problems for their issue and (so far) only one user complaint about it.