Auto Save function

I have used Scrivener for years and had no problems. However this morning I accidentally deleted a chunk of new work, and I tried to find it in the back up files (without success) So then I got a bit scared and thought I would back up the current doc on a memory stick just to be extra careful.

Now my current doc won’t save at all and keeps on popping up with this annoying box every couple of minutes saying I had no permission to save to this location and I have to contact the administrator.

I can’t even work because of the disruption with this box popping up like every minute… Obviously by copying onto a stick I have upset it… What can I do (and I need to establish a much more sound back up system long term Jenny wheeler

The underlying problem is likely that Scrivener sees the project it has opened/is trying to open as being read-only. Auto-save requires that it be writable. Perhaps it is now trying to work on the backup copy on the memory stick rather than the live project on your local internal hard or SSD drive.

One possibility is that the project it is attempting to work on is actually in the form of a single physical compressed .zip file. Windows can fake one out a bit, because it will let one navigate down into the contents of a .zip file… but those contents are not changeable while inside the .zip. One can extract (decompress) the contents of such back into live project form (regular folder (name ending in .scriv) containing subfolders and documents), which can subsequently be worked on.

Another possibility is that the project it is working on is in regular folder form, but somehow its properties got set to read-only. There is probably discussion of this in the forums. There is a discussion of this, from a Mac perspecctive, in the knowledgebase. … y-projects

For starters, I would assure which project Scrivener is opening by navigating in Windows (Windows Explorer or File Explorer or My Computer) to where your live version of the project is on your local internal drive, finding the project .scriv folder, navigating down into it and launching/opening the project index file (name ends in .scrivx), rather than launching Scrivener and having it default to most recently opened project. My guess is that you will be able to work on it as usual. Whereas opening the backup on the memory stick will likely not, for reasons discussed above.

As far as locations and backup strategies…

Relevant locations:

  • The live project’s location (wherever you told it to place it or let it default to when you first created it, likely in your account’s Documents folder). Ex: C:\Users\yourusername\Documents
  • Automatic backups location (wherever you told it to place them or let them default to, likely the following). Ex: C:\Users\yourusername\AppData\Local \Scrivener\Scrivener\Backups
    Can be set in Tools > Options > Backup, where you may also want to bump the number of backups to be retained up or to “Keep all backup files”. You also can set options there as to whether to save in compressed (.zip) form and whether to embed datetime stamp into the backup names.
  • Manual backups to whatever location desired via File > Back Up > Back Up To location. The datetime stamp option discussed above also get s applied there and you are again offered the option of backup up in compressed .zip form.

Here’s my approach to backups. Live project is in my Documents folder on local internal hard drive. Autosave backups are in the default location within AppData discussed above, with datetime stamp in name and compressed (.zip) option selected. I also regularly do manual backups as discussed above to DropBox, removable USB thumb/flash drives, and also burn copies of the backups to CDs/DVDs. Some of these need to be not just off-machine, but also, at least occassionally, off-site (DropBox cloud storage or bank safety deposit box or such). Key things are to be paranoid, backup frequently and get copies off-machine frequently and off-site at least occassionally AND do periodical test restores to assure that can actually retrieve material from the backups.

Others employ various other strategies, for a variety of reasons including sharing/syncing the live project between two machines, collaborating with someone else, personal preference, …

Hope that helps.