I am working on a large project that involves text,PDFs, image files, and audio files. Unfortunately, I cannot get Scrivener to back up my work; whenever I try to back up this project as a ZIP file, Scrivener freezes up completely.
Letting it sit and run overnight doesn’t work. It is still frozen when I get up in the morning. The upshot is that I have to force quit to get access to Scrivener again–and do not have a back-up of my work. This makes me nervous, as you might imagine.
A quick way to get a backup is to simply compress the file from the finder.
Find .scriv file in finder.
Right click (CTL click) on the file
Select “Compress QQQ” from the context menu.
Copy compressed file to backup media.
That said, I think there might be something wrong with your project. KB will need to evaluate this, but if you look in “Console” (Applications -> Utilities -> Console) do you see any errors related to scrivener?
Thank you, Jaysen! I didn’t realize that compressing the .scriv file would work. I’ll try that.
I just searched the console for any mentions of scrivener. I found two that seem to be related to me force-quitting it (5/2 and 5/8, “Exited: Terminated,” and only one other beyond that. It’s from 5/5, and it says, “Debugger() was called!” Thoughts?
(I’ve got a hella lotta adium errors, though–sheesh!)
There is something in Adium that spawns those errors … it might depend on version of Adium and version of MacOS, I can’t remember. There’ve been a number of threads on the adium about it … seems it is of no great significance, just fills up the console report with junk.
I have figured out that if I let Scrivener run long enough, it does, actually, make a backup–but Scrivener stays frozen even after the backup process is completed. So I have to force-quit Scrivener to get back into my project. Also unfortunate, given how long a backup takes: the entire time the backup is being generated, I can’t do anything else in Scrivener. But perhaps that part is by design?
What I like to do with projects that have a huge amount of research data is a little unorthodox. I like to keep the Draft separate from the research. This doesn’t happen often—I can only think of one project right now that requires this treatment, but in cases where the project is very large and takes minutes to backup, I’d rather keep the volatile, rapidly changing part of the project in a separate place so that I can feel free to back it up 12 times a day.
In other cases, the best solution is Referencing. If you don’t need your media to be right in the project itself, then sometimes it can be beneficial to drag all of the supporting files into the reference pane and use native applications to view them when necessary.
Of course, if after following Jaysen’s question, we discover your project isn’t that large after all, there could be something else that is at fault. As far as I know, even when a project is huge, there isn’t a “freeze” associated with the backup procedure. It’s entirely possible that something is messed up, but we’ll go there only if we need to.
This sounds suspiciously like a corrupt pdf that is preventing the back up. It will be hard to find if indeed it is one bad pdf. The previous threads on bad pdf issues suggested trying to open all the pdf files in something like TextEdit to find the culprit. (If indeed this is the issue.)
I think we are looking at either the PDF issue (Apollo16) or some other problem with the binary files. You could try opening each PDF up in preview to make sure they all work. Any PDFs that have problems should be removed from the project then rerun the backup. Do something similar with the other binaries, just make sure you use the default OSX tools not a third party tool.
What version of OSX are you running again?
Amber/KB, with 3.8G we wouldn’t be hitting some 2GB memory limit in the backup process would we? I haven’t seen anything on that before and suspect that the backup process isn’t actually reading anything into memory but just handing the work off to OS libs.
The ones inside the .scriv file itself. It sounds as though one of them may be sticking. It could be a memory problem, but since version 1.1 Scrivener has been more careful about freeing up memory after synchronising the strings of each file, so it’s unlikely.
At over three gigabytes, I would expect synchronisation to take a long time - but certainly not a whole night or more! A few minutes - ten at most I would think. Thus the problem is most likely a PDF file causing a problem.
The best way of checking is this:
Ctrl-click on the .scriv file in the Finder and select “Show Package Contents”.
Switch to the Finder list view and sort by kind.
Move all of the PDF files out of the .scriv package and into a temporary folder.
Move the PDF files back into the .scriv package (via the Finder) ten at a time:
a) After dragging ten back into the .scriv package, launch Scrivener again and open the project. If the search strings won’t sync, then you know the problem must be with one of the PDF files you just dragged in, so drag them out again and then repeat the process but with one file at a time, until you find the file causing the problems (and then leave that out of the project).
b) If the search strings do sync okay, close Scrivener, drag another ten PDF files back into the package, then launch Scrivener again and open the project again.
c) Go to the File menu and hold down the Control key while clicking on Save. This will force the strings to sync. If it freezes, you know one of the ten files you just brought in was dodgy, so can go through one by one again as in 4b.
d) Repeat this process until you have all files back in the project.
By the end of this process, you should have weeded out a couple of PDF files that are causing problems. If so, could you please send me one of the PDF files to support At literatureandlatte DOT com?
I would be happy to take a look at the project myself, but unfortunately at over 3GB that is rather difficult.
