Binder and files lost post-crash

I’ve been working on my first scrivener project for about a week, so a lot of the project information was in the binder: how files relate, research I’ve gathered, and so on. Then my laptop crashed in the middle. I thought this wouldn’t be a problem because of autosave (and I always save with CTRL-S anyway, out of paranoia and habit).

I was horrified to find on restarting that my binder had reverted to a state about five or six days old, and tons of work was missing. But it’s stranger than that: my “Files” folder in the .scriv project folder actually seem to include, in separate numbered text files, all the notes I’ve taken. And if, within scrivener, I’ve added more notes in the last five days to a document I created a week ago, all the changes are there. So it seems like the binder is not being autosaved, though everything I type actually is.

I really want to fix this: I love scrivener and am new to it, but obviously the main advantage it has over using a multitude of separate text files is its ability to organise material, which is what I now feel like I can’t rely on.


OK - I’ve done some more reading around and, if I understand correctly, the file structure is saved in a .scriv file, while the individual documents are saved as text files in the Files/Docs folder of the project. But is there a reason my .scriv file wasn’t saving changes? Do I have to quit scrivener every time I want to save the file structure? Does autosave only save text files, and not the .scriv file? I understand that automatic backups are only created on exiting the program (and/or on startup) - but is that true of regular saves as well?


Hi Micha,

In Windows, a Scrivener project is a folder (name ending in .scriv) that contains a .scrivx index file plus a number of folders and lots of files. Basically, a database. Which, within Scrivener, presents as a single hierarchical project.

On the Mac, same deal, but is apparently presented (details hidden somewhat) as a single “package”.

I’ll try to do a quick search and get back to you with suggestions.

Immediate concern… making safety copies of the project’s backup files, in the hopes of there still being one with a relatively current .scrivx index (and associated files). This needs to be done outside of Scrivener, assuming the number of backups retained is still defaulted to 5, to avoid Scrivener replacing them, one at a time, with new backups as you try to work the problem.
The backups will be either folders (names ending in .scriv) or single compressed files (names ending in .zip), possibly with date time stamps added to their names, depending on how that option was set. If those can be located, first thing is to make copies of them, elsewhere, for safety sake.
The default location of the backups is

With those safety copies made, the next thing to do is probably to tell Scrivener to retain more than the default 5 backups. In Scrivener, Tools > Options > Backup and change “Retain backup files:” to retain a larger number of backups.

With that done, you are at the point of trying to recover/rebuild, hopefully from backups. If not, manually or semi-manually. For that, I’m going to have to search for some references or discussions here on the forums, searching on “restore”, etc.

Hopefully someone more experienced and expert than I will post here regarding that. The manual discusses backup/restore. And there have been discussions of similar situations here on the forums.

The ideal situation is that the most recent backup made before the crash exists. If it does and it is a .scriv folder, hopefully you can open it (navigate to in in Scrivener or just navigate to it in File Explorer or My Computer and launch it by doubleclicking the .scrivx index file inside it. If it does exist but is a .zip file, you’ll first need to unzip (decompress via “extract all”) its contents, which will be a .scriv folder, etc. and then open it as discussed earlier).

I’ll go search now and see what more I can supply you or point you to.

Other things to consider while working on this… cause of your computer’s crash, was the project by any chance being stored on “cloud” storage such as DropBox…

In the Files subfolder of the project, there is a file named search.indexes
It contains information, in structured readable form, that ties meaningful Scrivener binder item names to their underlying numeric operating system file system names.

It is in structured plain text form (XML). While one can view its contents with something as basic as the Notepad text editor, it is best viewed with an XML aware text editor that recognizes and presents the structure. For Windows, Mac and Linux, UltraEdit is one such (costs, but free time limited eval available)… there are others, probably including several free ones (do a search on “free XML viewer” or “free XML editor”).

Worst case, this may be of assistance if have to manually rebuild the project from the numerous .rtf files.

Back in a while with more…

The project.scrivx file auto-saves regularly and even makes an auto-save copy as the first fallback. It sounds like these files got corrupted in the computer crash (e.g. if the auto-save was in process, both the main file and the auot-save copy would’ve been slammed), so that when Scrivener next opened the project, it had to fall back on an older copy of the file. Scrivener creates a backup copy of the .scrivx file and saves it within the project when the project is successfully opened (separate from a full project backup; this is a copy of just that binder file). It’s specifically for a case like this, where both the main .scrivx file and the newer backup have been damaged; Scrivener will automatically then try to recover from the backup version. If you’d left the project open for several days, the most recent copy of the binder.backup file would have been that many days old, accounting for the outdated binder structure when the project opened.

If you have a complete project backup newer than the version of the binder you’re seeing now, your simplest answer may be to recover that one, then import any newer files from the Files/Docs folder of the corrupted project. Scrivener’s default settings are to create a full backup when you close the project, but if you had modified them to create a backup on every manual save or if you ever used File > Back Up > Back Up To… or File > Back Up > Back Up Now, you may have a newer copy. Even if not, I would strongly recommend finding your backups (by default the automatic ones will be in C:\Users\YOURUSERNAME\AppData\Local\Scrivener\Scrivener\Backups, also accessible via the Backup tab in Tools > Options) and copying all the ones for this project to another location, to avoid overwriting them with newer backups during the recovery process, just in case you need to access them.

Happily, it sounds like you do still have all the actual files in the project, they’re just not all appearing in the binder? If all the missing items are text files, one way to recover them is simply to start creating new items in the binder. As you do so, they’ll start repopulating with the missing text, as Scrivener will recognise that a file matching the new ID already exists.

If you have other items like PDFs, images, etc., it will be a little trickier, as these can’t be regenerated the same way. You will need to re-import them, which means that you’ll lose any internal references and that if you had a synopsis or document notes associated with the file, they’ll need to be copied into the new version’s synopsis and notes. (The document notes and synopsis themselves will reappear when using the “Add New” trick above, they’ll just be associated with a blank document. You can copy them from there to the correct file once you re-import the non-text item, and then trash the blank document.)

I’d suggest first making a zipped backup of the project (File > Back Up > Back Up To…), then navigating into the project’s Files\Docs folder and finding any non-text items here that are not shown anywhere in the binder. In Windows Explorer you can sort by file type or by date; either of these may help you track down any errant items. If you find any that are in the project folder but not in the binder, move them out of the folder, e.g. to the desktop. Then, once it’s no longer in the project folder, drag it from the new location to the project’s binder in Scrivener to import it again. This will make a new copy of the file in the project folder (hence removing the original first, so you don’t bulk up your project folder with duplicates).

If you do have a lot of non-text files that have notes and synopses and are tied up with internal references in your project, it is possible to edit the project.scrivx file directly to add the items back in using their original IDs (thus keeping everything together), but it’s a bit more technically complicated since you’re modifying the XML. If you’re comfortable with that, go ahead and give it a whirl, just be sure you make the project backup first. In this case, you’re just going to be adding in the references to the missing items by hand, essentially, using the filename numbers that you see in the Files/Docs folder. If you haven’t worked with XML before, this isn’t your best option, but if you’re in a situation where there are a lot of highly-associated non-text files, you could send the zipped backup of the project to AT literatureandlatte DOT com with a reference to this thread, attn: Jennifer, and I’ll see what I can do.

Thank you both, Jennifer and SpringfieldMH, for your help. This has been a crash course in scrivener’s backup system. In the end, I pretty much reconstituted the project manually: I had had the project open for several days, so I didn’t have backups (simply because I hadn’t closed the program), and whatever happened when the laptop crashed, my search.indexes file also referred back to a much older version. I didn’t get any error messages when I re-opened scrivener after the crash: it must have just silently reverted, as Jennifer said, to a previous backup copy. But I’m very glad to hear that the project.scrivx file does autosave, and I’ll be sure to close scrivener more often in the future.


Take a look too at the Backup settings in Tools > Options. If you do leave the project open for extended periods, enabling the option to create a backup when doing a manual save may work better for you, although if you habitually Ctrl+S every few seconds that will get old pretty fast. :wink: Do check these out, though, to make sure they’re set up in a way that’s going to give you the most benefit–you may want to change the backup location, increase the number of backups, etc. A lot of people point the backups to a Dropbox folder or other synced folder that will automatically proliferate the backups to your other linked machines. You definitely want to have some system in place, manual or automatic, to store backups off your computer, in case of hard drive failure, stolen laptop and so on.

Note also that you can use File > Back Up > Back Up Now at any point while working to run the auto-backup routine. You can also use File > Back Up > Back Up To… to create a manual backup at any location you choose, with whatever file name you want, not associated with the auto backups. This option is great for milestone copies, since it’s not going to roll off later to make room for newer backups. It’s also handy for saving to an external drive. Both these commands can be added buttons to the main toolbar via Tools > Customize Toolbars.