Scrivener hangs on opening a project

Well, for the first time in several years, I was unable to open one of my Scrivener projects. When I tried to open it, Scrivener hanged (“application not responding”) and the only thing to do was to force-quit Scrivener.

No problem, it happens. I actually was able to recover a very recent version of the project from a backup. But I would like to ask a couple of questions.

(1) My Scrivener preferences are set to “back up on project close” and to keep the 5 most recent backups. When I checked the Scrivener Backup folder, the most recent backup was dated May 30, 2016. I have actually opened and closed this Scrivener project several times in the past few days. Why did Scrivener not make more recent backups?

(2) I use CrashPlan for online backups. But Scrivener projects have a complex structure. CrashPlan showed me up to a dozen versions for each compoment of the project: Docs, binder.backup, search.indexes, user.lock, [ProjectTitle].scrivx, and so on. When I tried to restore the project as a whole, it didn’t work: CrashPlan had already made a backup of the corrupted project, and of course Scrivener hanged when I tried to open it. – So my question is: When a Scrivener project doesn’t open, which component is responsible? Knowing this, I could have restored an earlier verson of that particular component, copy it into the project package, and maybe I could have opened the project again.

(3) To conclude, fortunately I also make monthly backups of my entire internal disk on an external disk with SuperDuper, and was able to recover a very recent version of my project. Nothing important wos lost.

But … having opened and closed this recovered copy of the project, I have seen that Scrivener still does not back it up.

What’s the best way to solve any further issues with this Scrivener project?

Xuanying

I would run some tests of your backup settings with a test project (just create a new Blank project and do some test open and close operations with trivial changes made to the editor each time) to make sure it is working in general the way you expect. Also click the the button at the bottom of the backup preference pane and make sure the folder there is the same one you’re looking at otherwise in Finder.

Next, make sure the project itself is set to back up. It is possible to exclude a document from automatic backups with the File/Back Up/Exclude from Automatic Backups menu toggle.

Lastly, if everything else looks set up correctly, check the location of the project itself and make sure it is not in the backup folder. Projects opened from within the backup folder will not be themselves backed up. This is a safety precaution against the backups themselves overwriting older backups from the same set.

All right as for the project itself—it may even be okay. The condition you describe is not uncommon in projects with a lot of PDF and WebArchive files within them, but there are other causes as well, even unexpected text formatting or embedded images.

So what can often be done then is remove the project’s “ui.plist” file, in its package subfolder “Settings”, which among all other project display settings, will reset the editor to viewing nothing. I.e. if the corrupted web page or whatever is the last thing you looked at, then every time you load the project it will continue attempting to load that file leading to a cycle of crashing.

If the project loads fine after doing that, then your goal will be to root out the file that caused the crashing and once you do, remove its data file from the Files/Docs subfolder. Oftentimes and easy way to find it is to use Quick Look in that folder until Finder crashes—it uses the same display engine after all.

If Quick Look doesn’t find it, you can use Scrivener’s “search.indexes” file, in the Files subfolder, to help locate the numbered file by its binder title. For example if a PDF named “Uses of pollen in historic medicine” is the thing crashing Scrivener, you can open that file in TextEdit, search for “Uses of pollen…”, and find the “ID” number for that item nearby. Say it’s 197, that means going into the Files/Docs folder and dragging 197.pdf out of the project.

If you’d rather, we can help you take a look at the project through tech support. It may take a few days to get back with you though as we’re still catching up from over the holidays.

P.S. Regarding your backup service, a Mac package format is a folder of files, but the whole thing should be considered one coherent “file”. Thus to successfully restore such a format the system needs to be capable of restoring a folder and all of its subdocuments at the state they were in at a particular snapshot, when the backup was taken. TimeMachine works the exact same way internally—versions upon versions upon versions of the files that change frequently, but it hides that complexity from you and presents a coherent restoration of those versions in matching timeframes as one single package.