I need to work on the same Scrivener projects on two different iMacs and a laptop, all synchronized with Dropbox. I’ve followed the advice on this forum not to try to synch raw .scriv bundles, but to use the zip files created by “File | Backup Project To”. Which is hideously inconvenient and error-prone.
My typical workflow on any one computer goes like:
Copy the latest backup zip file from my Dropbox folder to my desktop. (Trying to unzip it in place sends Dropbox into a flurry of activity and, very occasionally, confusion when the .scriv bundle is yanked out from under it.)
Unzip the zip-file copy on my desktop to a .scriv file.
Delete the zip-file copy.
Open the .scriv file and work on it.
When I’m done, remember to use “Backup Project To”.
Delete the working .scriv file copy on my desktop.
A tiny error or omission anywhere along that chain can delete hours of work – or at best leave me with forked versions of the backups that need to be manually and tediously merged. So please make Scrivener do most of those housekeeping steps for me.
I’d like to be able to open a backup zip file directly into Scrivener. Scrivener can make a working copy wherever it wants and do all its autosaving there, but any explicit save command or closing Scrivener should trigger a new timestamped zipped project backup in the same directory as the original zip file.
That would make the whole experience almost as transparent as if Dropbox and Scrivener could actually cope with each other’s use of the file system.
I have been thinking about something like this (although not for the initial 2.0 release), but it would be hugely problematic. For a start, saves would be incredibly slow as it would have to zip the entire project each time (rather than just save the individual changes - so you could be saving 100MB instead of 5KB with each save). If this happened at every auto-save, it would become unusable. If it was left only to manual saves, if the program crashed or quit unexpectedly, you would be left with a zip file that hasn’t been updated with your latest changes and only the working copy with the changes - which would presumably be hidden somewhere since you wanted it to be transparent.
So it’s quite a problem - but one I do intend to think some more about post-2.0.
what about saving individual binder file changes on every autosave, but only saving full zip once every X times? Then you can use a status file to recover from a crash.
the downside is that you will use more disk space, but it could be managed in such a way as to only use disk for actual changed files.
I understand about the autosaves – that’s why I suggested the working copy. It wouldn’t really be “hidden” if it’s in one of the logical places I’d go looking for it in an emergency, like Library|Application Support|Scrivener. And if Scrivener automatically opens the last project it was working on after a crash (I wouldn’t know), then I wouldn’t even need to go looking.
By “transparent”, I don’t mean that the location and even the existence of the working file are top secret, just that I don’t have to create the working file manually every single time I want to work on my project.
Unfortunately, you built Scrivener too solidly for your nightmare scenario to sound very scary to me. I haven’t had Scrivener crash on me once in almost two years – whereas the consequences of your hypothetical crash are exactly what I’m living with right now several times a year (due to my human frailty). Cutting the frequency of those messes to maybe once a year (if I’m really unlucky) just doesn’t sound “hugely problematic” to me.
I can imagine that changing the behavior for manual saves and quitting could get very complicated. But even just automatically unzipping the backup to a working file in Application Support, leaving it to the user to remember to save a new backup, would be a huge improvement. Only one step more than using Scrivener purely locally, instead of four or five steps more.
Don’t know if this would work at all but it’ll only cost you two cents, so…
What if, after the initial loading of a project, Scrivener creates a dated, non-zipped copy of the project in the “backup” directory designated by the user. Every time the auto-save kicks in, it saves the changes in two places instead of just one. The non-zipped copy would always be in a “closed” state. In other words, no transitory files like you have in the main project as it’s being edited.
When an explicit backup is called for, the non-zipped copy is zipped and labeled with a new date, and a new non-zipped, newly date-stamped copy is created in the backup directory.
I’m sure there are all sorts of issues with implementing something like this, but it might solve the “long save-time” issue at least, even if it does bring up 10 other issues in it’s place.
I haven’t had Scrivener crash on me once in almost two years – whereas the consequences of your hypothetical crash are exactly what I’m living with right now several times a year (due to my human frailty). Cutting the frequency of those messes to maybe once a year (if I’m really unlucky) just doesn’t sound “hugely problematic” to me.