Scrivener Won't Open My Project

I tried transferring a large-ish Scrivener project (24.7 mb) from a MacBook to an 800 mhz G4 PowerBook. When I doubleclick on the project, Scrivener opens; I get the beachball for a minute or so, and then nothing happens.

When I try to open the project from the Open menu, the same thing happens–except that, at the end, Scrivener displays a dialog that reads “The document ‘Catholicisim.scriv’ could not be opened.”

In the System log, the following message appears, no matter whether I’ve doubleclicked the project or tried to open it from the Open menu:

May 10 06:03:59 Laptop-One kernel[0]: vnode: table is full
May 10 06:03:59 Laptop-One kernel[0]: 9216 desired, 9216 numvnodes, 0 free, 0 inactive

I’ve tried zipping the file before moving it; moving it unzipped; through a network file share; through iChat; by CD. Same result each time.

The file works fine still on the MacBook.

Any ideas?


UPDATE: Found my answer here: … 00027.html

Running sysctl -w kern.maxvnodes=67584 as admin allowed Scrivener to open the project.

This project has a TON of individual files in it, and I suspect that this may indicate that there is, for practical purposes, an upper end on the number of individual files a project may contain. (See the Apple list link above.)

On the other hand, Scrivener should not need to have all the files in a project open, so theoretically, it could contain far more files, as long as some much smaller number were open. So, I’m not sure why I ran into this problem, unless, when Scrivener opens a project, it’s briefly opening all of the files therein.

I’m also not sure why it’s happening on one computer and not the other(s). The PowerBook has less memory (only 512 mb), so that may have something to do with it–perhaps OS X allocates maxvnodes on the basis of installed memory?


Upon opening a project, Scrivener only ever opens the visible documents. Besides which, “open documents” inside a project is slightly different to the OS X concept of “open documents”. All in all, I’d say that this is an issue with your machine rather than an issue with Scrivener.
All the best,

Well, yes and no. This PowerBook has been my primary Scrivener machine since the days of Scrivener Gold–in fact, everything I’ve written in the past year has been written in Scrivener or Scrivener Gold (and I can’t imagine writing anymore without it), and this project actually started out on this machine.

Other Scrivener projects with far fewer docs open just fine; this one, which has 4,653 files inside the .scriv package, has caused Scrivener, on this machine, to choke. Nothing else, in any other program on this same machine, throws up the vnodes error. In other words, it’s Scrivener-specific, file-specific, and, yes, in my current experience, machine-specific.

Since I can work around this (I have to set maxvnodes after every restart, but that’s no big deal), I’m not particularly concerned. At this point, I think it’s probably just a good idea to keep this experience in mind, in case others experience it in the future.

I’m just not really sure why you would experience this. It may be that OS X itself checks the file package (.scriv package) and determines file handles based on the files inside, but I don’t see why it could. Scrivener handles all of the file reading itself, and it doesn’t attempt to load anything into memory unless it is needed. Hmm… So it may well be an OS X thing, based on the fact that Scrivener uses a package file format. But I really don’t know.

Is the quick search XML index perhaps a culprit?


You might try opening that Scrivener project; then opening the terminal and running this command that will create an AllOpenFiles listing on your desktop:

sudo lsof > ~/Desktop/AllOpenFiles

You need to run this as root in order to have all the system files listed. lsof has three trillion options if you want to modify the output otherwise just open the resulting file on your desktop in any text editor. For reference, on my system right now there are 3,520 open files. You can just run down the list and see if there are any processes that have thousands of files open.


Open Activity Monitor, double-click Scrivener in the list, and then click on the “Open Files and Ports” tab. Scroll down to the bottom of the list.

Now, open a Scrivener project, and watch the files fly. When a project is first opened in Scrivener, it appears that every file in the .scriv package is opened briefly. Only after each one has been opened and closed does the project appear onscreen.

With my large project, it’s that behavior that’s preventing it from opening, because it’s maxing out the vnodes.


Hmm… As far as I can see, the files opened by Scrivener are not the internal project files, but files associated with the interface - the numerous TIF files used for the buttons, the interface files and so on and so forth. There are hundreds of them, because Scrivener has a complicated interface. But I cannot see anything more alarming than with similar interfaces…


I’m not talking about when opening Scrivener itself, nor when Scrivener simply has a project open. In those cases, yes, the files that you mention are the ones open. But if you follow the steps I outlined and watch the list of Open Files and Ports in Activity Monitor while a project is opening, you’ll see every file inside the project’s .scriv package briefly open and then close.

The list will look something like this (obviously, this is just a small portion–in the case of this project, thousands of files scroll by):

Those all disappear before the project appears on screen (or fails to appear, if the vnode table fills up before each file is opened and closed).

Once the project is open, then only the actual files that are being accessed in the project show up in the list.

As I’ve said before, it doesn’t bother me too much, because I know how to work around it. But if, as mentioned on another thread, some folks are using Scrivener as something more like a database app, they may very well start running into this same problem.


Hi Scott, I’ve sent you an e-mail to the address with which you registered for this forum with details of a build that I hope fixes this issue, though I’m by no means confident that it will…