Anyone else seen this?

Here’s another problem I’ve been meaning to write up for some time. Occasionally, while I’m editing, and my project tries to autosave, this happens:

I click on okay, and continue on my way, and then I don’t see it again for some time. (I have my autosave interval set fairly frequently, trusting technology as little as I do, but I still might not see the problem again for days.)

I’ll say it anyway, though it ought to be obvious: I have plenty of space (764 GB) and I do have write access.

The one thing I will say is that it started after my update to RC9, but I also assigned drive F as a virtual drive around the same time I updated to RC9, so perhaps it’s a Windows 10 thing (a fluky Windows 10 thing that happens infrequently) and not a Scrivener thing.

But, just in case it isn’t Windows 10 acting up…

This error shows that your project document file has been locked from an external process and Scrivener can not write your latest changes. This might happen if you have your project placed inside a Cloud shared folder, and the project is under a continuous sync.

Well, my mapped F-drive does point to a sub-folder of my dropbox, so, yes, this project is in the cloud. I guess I need to change my auto-save interval to a bit higher.

Thanks for explaining this to me.

From your screenshot it is not visible the cloud syncing root path you are using. I would recommend using default cloud syncing paths, like “Dropbox”, “OneDrive”, etc. and not “MyDropbox”, “USER_OneDrive” paths, as Scrivener auto-chooses the best crash-protected file write algorithm based on the project location. If you use custom folder names, Scrivener will fail auto-detection. The above message shows that your project folder is not auto-recognized as a cloud syncing folder. Please, let me know the full sync-folder path, excluding the project path if you do not like revealing it.

As a temporary workaround, try mapping to your project via the normal Dropbox path instead of using your mapped F: drive. If the problem/behavior goes away, then you know for a fact there’s something about that mapping that is causing havoc.

I would, but the whole reason I mapped the drive so that I can show the full path in the title bar of Scrivener (which, with a file in my dropbox, can lead to some very long titles if not mapped!)

I think the real problem isn’t that it’s in the cloud, slowly updating, but that I had been updating too often (somehow I’d set it to update after 5 seconds of inactivity. I guess I pause frequently and it was still updating from last time. It’s set to 30 seconds now, which should give dropbox time to do its thing.)

I’ll see if that works first before unmapping.

Hence the “temporary” as a troubleshooting step. If you stop using the mapping and the problem goes away, you know that you need to tackle the base problem (long path name) in a different way.