This is happening to all of my projects, both old and newly created. It will work fine about 75% of the time. But the remaining 25% of the time it will throw an exception whenever it goes to autosave. The error it gives me contains the message “Could not rename project rtf to .old rtf file name.” If I close and reopen the project, I find that I’ve lost everything I’ve typed since receiving that message and clicking on “OK”.
Unfortunately, because this is happening across all of my projects, I can’t trust Scrivener 3 for Windows until it receives some kind of service pack. This is a bug that should never happen. A customer should never feel like they’re going to lose their data, and that’s how I feel right now.
That has to be a permissions, firewall, or antivirus problem.
I’m with the Dr Major on this one, @NatR.
Based on the message–thank you for posting it–it’s got to be something local to your PC. You may want to start by temporally disabling your AV to see if that resolves the issue. If it does, whitelist Scrivener.
Whitelist it either way, @NatR.
I use Windows Defender for antivirus, and the permissions on my projects folder are wide open. I can “save as” to my heart’s content, but when Scrivener tries to auto-save the exception gets thrown.
I’ve added the Scrivener3 .exe to the Windows firewall whitelist, but I don’t understand why that should matter. It’s not reaching out to something external to the system. Everything is local.
The licensing code in Scrivener does require a network connection to the Paddle licensing servers on the Internet, though, and Scrivener does have the web import functionality, so the scrivener3.exe requires the capability to open network connections.
That makes a lot more sense. For what it’s worth, I whitelisted Scrivener3.exe in the Windows firewall and I haven’t had the issue at all today.
Thanks for all of the tips!
That’s great news. Thank you for the confirmation, I’m sure it’ll help someone else.
I’ve been having the same issue since I upgraded a few months ago, but since it’s intermittent and I’ve always just clicked it away and not lost any work I’ve ignored it so far.
I tried whitelisting Scrivener in the Windows firewall, but it has made no difference to the frequency of the error message.
What AV are you using? You may need to whitelist Scrivener in that as well so that it stops trying to intercept any file read/write activities Scrivener is performing against the file systems.
The AV is what’s included as part of Windows Security, and I can’t see any way to whitelist applications in that.
I googled “how to whitelist an app in windows defender”.
The first hit was this Microsoft page, which provides step by step instructions.
Here is what the exclusions setting looked like after I whitelisted Calibre, an ebook management app that uses the same development framework as Scrivener, and which didn’t work correctly until I whitelisted it:
Great! I’ll give that a try.
I excluded the project folder for Scrivener from Windows Antivirus scans, and I’m still getting that same error message.
Is there something special about the folder location? For example is it inside dropbox, onedrive, or some other cloud replicator? I have seen this issue with some programs when it’s inside a program folder that is making copies of your files in the background because for the brief period it’s being replicated, the file’s name is locked. Some programs aren’t expecting this and throw an exception because they wrote the temporary file for the save and once it was complete and closed, they were trying to rename it. I’m not seeing this with dropbox currently, but it might be an avenue of investigation if something is processing your files automatically for you.
It’s just in the standard Windows Document folder:
I do have a separate cloud backup app running. I will see if I can keep that from accessing the Scrivener folder and see if that helps.
If it was the cloud backup app, see if it supports a mode that uses the Windows Volume Shadow Copy Service (also known as VSS). Using this allows backup apps to take a temporary snapshot of the entire disk volume – which causes a pause of no more than 10 seconds – and then perform their backups from that temporary snapshot. This is how most Windows-aware server backup apps perform, and it allows them to completely back up all data in a consistent state without running into file locking issues while applications are still actively writing to the disk.
Applications are not in the project folder, though.
What made you think backups had anything to do with it?