Default to "keep all backup files"

If there’s one thing that aggravates me personally about Scrivener (when I uninstall/reinstall it for various testing or other reasons)… and which appears to bite folks when they encounter the need to recover from backups… it is the default of “only keep 5 most recent backup files”. By the time it occurs to me that I need to change this following a install, a significant number of older backups are gone). And folks dealing with project corruption issues, who have never raised the number of backups to be retained, or even set to “keep all”, often burn through the small default number of backups before they realize the impact that has on the survival of older good backups.

Obviously, one should also be keeping copies of backups elsewhere also, preferably completely off the computer. I do. But this still bites me from time to time and I see in the forums where it bites others from time to time.

Anyway, I would suggest defaulting to “keep all backup files” (and probably also “use date in backup file names”), to maximize safety and intelligibility of backups. Or also offer and default to markedly higher numbers (100, 250, 1000, ?).

Thanks. To be clear, I use and love, love, love Scrivener.

The trouble with having that option on by default is that it could severely clutter up your hard drive. If you have a 100MB project, that would be a gigabyte of your hard drive gone after 10 cycles of opening and closing the app. There’s no way any app should take up that sort of space without the user explicitly turning on a setting.

All the best,

Second Keith’s observation. I’ve seen what a rogue backup program can do to disk space, and it’s not pretty.


At the very least have it be an option you can select during the install (for Windows) or the first time you fire up Scrivener?

Really good suggestion.

Keith/Kathrine - I have always assumed that you didn’t default to “Keep all” due to concerns about Scrivener eating up hard disk space. That is certainly a valid approach. But unfortunately there are people who don’t think about backups until after there is a problem and it’s too late. I realize that there is only so much you can do and users have to ultimately take responsibility for their data. But devinganger’s suggestion has merit, and it might get some of the new users to consider their backup strategy. Could you please consider it. Respectfully - wouldn’t it be preferable to see posts entitled “Lost a lot of hard drive space” instead of “Lost a lot of work”?

Similarly, I can always delete or move old backups to free up space. I can’t create backups out of thin air to replace lost work.

Except that if you abruptly run out of disk space, you are pretty much guaranteed to lose whatever you were trying to save at the time, and it won’t necessarily be a Scrivener project. You’re also going to bring all work on that system to a screeching halt until space is recovered, and someone who doesn’t think about backups isn’t going to think about disk space, either.

Keith used the example of a 100 MB project, but we have users with multi-gigabyte projects out there. That’s the kind of thing that can very quickly consume even very substantial hard drives.

Picture, if you will, the howls of dismay when a user is trying to save video of his kid’s 1st birthday, only to have Photos crash on him because it runs out of disk space. On further investigation, he finds that he’s got a couple hundred Scrivener backups going back to before the kid was born cluttering the system. Do you want to handle that support query?


No, but you can turn off the options to trim backups.

We very, very rarely hear from users who have lost a lot of work, so this has never been an issue, and the fact is that the option is there for those who want it. We’ll be continuing to use the current default, for the reasons given.

All the best,

Makes sense, KB. Thanks for sharing the rationale!