Feature Requests: Zip Backup

Hi. I am nearly at writing nirvana with Scrivener. The main speed bumps I have are around the backup process. As such I have two requests. Also, I’ve possibly spotted a bug. If so, I’ll post that in the bug forum.

1 - I despise the current default naming scheme for backups. Here’s the possible bug - I have “Use Date in Backup File Names” unchecked (in the option/backup panel), but the backup file name defaults to using the date and time. Checking the box doesn’t change the default behavior. Bug?
How I would like the backups to be named would be the following:

Project Name - Increment #.scvz

The increment number would be configurable for the number of digits. Here’s why; when I’m mucking about with the files, I am usually only interested in the latest version. A long name with the date and time is visual garbage. I don’t want to be changing the sort parameters of the directory. I want a name that by (Windows) default will be at the top or bottom of the directory listing. The date and time are included in the zip files metadata, so if I do need to refer to it, it’s there. It’s counterproductive (for me) to have it in my face.

2 - What did I mean by the “scvz” extension? That leads to my second request. I would LOVE the ability to skip the “backup” process all together and have Scrivener treat zipped Scrivener projects as “the file format”. I realize that with everything Scrivener is doing within the project directory this could be potentially difficult (he says with a knowing chuckle), but it could work quite readily if Scrivener used a “scratch disk” approach. In that approach, when a project is loaded, Scrivener unzips the project to it’s scratch disk and proceeds normally. And when the file is saved, the project in the scratch disk is zipped up and saved. The user could then treat a Scrivener project as a file instead of a directory that has to be managed and zipped and unzipped, etc.
Thus the weird extension. A zipped project file would need to be automatically recognized as a zipped Scrivener project (both by the software and the user). A new extension name would nicely solve that.

My reason for these requests is that in the course of a typical day I will write across three different machines (home desktop, work desktop and netbook). At the moment I have three live projects. So I end up zipping, unzipping quite a bit. Being able to treat a Scrivener project as “just another file” would allow a huge wealth of existing tools to be put to use in managing my workflow.

Thanks for your time.

I asked for a similar feature (zip or similar file container), but it appears that such a format interferes with Scrivener’s ability to provide external access to unsupported research documents, and adversely affects the memory footprint of an open project as well.


As for sharing a project across multiple machines… can you make use of a service like dropbox.com? If you’re careful about allowing syncing to complete after closing and before opening, it works like a charm. Just follow the guidelines in the manual under “Scrivener Everywhere”.

If Scrivener used the scratch disk approach, the memory issues KB mentions in your linked thread would not be a problem. What I am suggesting is that the archiving of the project be made invisible to the user. The net effect is that if and when the user goes to do anything with the project (external to Scrivener), such as using archiving tools of their choice, they will encounter a single file for the project.

Later today I will write up a better description of what I am suggesting.

The current situation is extremely frustrating. I want the machine to handle the repetitive chores of data management. That’s what computers are good at.

As for Dropbox… I FTP backups between my machines and my website. The only thing Dropbox can offer me is the ability for a company (Dropbox) in another country to have access to my files without my permission. I’m not knocking the idea of Dropbox, but it is essentially an automated FTP system. I’d rather keep control over my data. Is Dropbox really popular among Mac users? Is that why it’s mentioned so much on these forums? Or is it the only free cloud storage service?

Last time I checked, FTP didn’t do synchronizations of edits and deletes, so no, I don’t think they’re equivalent at all, unless you equate all network-based file transfer protocols. As for popularity, I think Dropbox is popular because it was the first synchronizing cloud storage solution that the developer and staff found acceptable for use with Scrivener bundles. It’s cross-platform, available via web interface, and apparently iOS devices can also access it – a big plus when it comes to the future iphone/ipad Scrivener apps.

I think the farther out from standard PC & Mac computers we get, the less viable a scratch disk solution will be, but then I’ve never tried to implement such a thing (I’m not a desktop application programmer). Is there a Widows/Mac/iOS/Android/WebOS compatible solution for that kind of thing?

I’d like to support Metonymy’s request about changing the backup naming scheme. With the way it is now I have to rename the backups, which is not convenient. Allow the user to choose the scheme, and that will probably satisfy everyone.

As for storing the backups in the cloud or on one’s website, the second case is essentially the same as the first one, i.e. the ability for a third party to potentially have access to your data. :slight_smile: The only difference is that this time it’s your hosting provider instead of cloud sync solution provider. Unless, of course, you host your website yourself on your own private server, which is the only way you can say that you truly keep control over your data.

As a solution to this particular problem I personally use TrueCrypt container in which the Scrivener project resides and which can be safely synced to the cloud. Sure, it adds a couple of steps to your everyday routine (mount/dismount), but it’s not that big a price for the convenience of being able to sync/back up to the cloud and keeping a peace of mind at the same time. :slight_smile:

So what you are saying is that Dropbox as some sort of version control system built in? It still wouldn’t be useful for me as I already use a versioning control system and my own encrypted website. Further, I live in New Zealand and we have data caps here. Traffic within N.Z. is not counted against the data cap. Now I’m not moving GBs of Scrivener project data around, but I still don’t want to pay to send my data overseas (encrypted even) to be held by Dropbox. They dropped the ball BIG TIME and I see absolutely no reason to trust them.

Next post I will elaborate on my original post.

This post is an attempt to clarify what I intended in the OP. Still drinking my morning coffee so clarity may be an unreachable goal at the moment.

Current Scrivener Project Scheme:

A Scrivener project is maintained in a dedicated directory on a HD.

Scrivener can generate a zipped copy of the project.

A zipped backup is generated automatically and stored in (on Windows 7):

A user can manually generate a zipped backup of a project.

To use a zipped project, the user must overwrite the HD project directory.

The features I would like to see added:

1 - The ability for Scrivener to treat the HD project directory as a scratch (disk) project.

2 - The loading and saving of zip compressed files to be made transparent to the user.

The above two additions could be configurable. In other words, Scrivener can behave as it currently does, but you could check a few options to enable these features. The way I would like to be able to work with files is not for everyone. Some people stuff huge media files into their writing projects and some people work on a single machine, but if you work with smaller Scrivener projects (text mostly) and/or work on multiple machines, these ideas could save the user some brains cells.

1 - Scratch Project. This is more of an approach than a new feature. All this would require is for Scrivener to compare a version property when a project is loaded.
If the loading project has a later version than the scratch project, the scratch project is updated from the loading project.
If they are equal, Scrivener does not update the scratch project.
If the loading project is an earlier version, Scrivener would ask the user what they want to do. Perhaps the user wants to roll back to an earlier version. Or maybe they’re loading an older version of the project by mistake.

2 - Transparent zips. Obviously this means that a project is saved and loaded in/from zip compressed format. A new file extension would be used to readily identify Scrivener projects (.scvx or .scvz something like that). Also I would obviously like to see the addition of the versioning naming scheme I mentioned in the OP.

The above could work with lots of big media files, but it would probably be more cumbersome than useful. Again, that’s why I suggest these be configurable.