Problem Saving

Last night Scrivener displayed some worrisome behavior relating to saving files. I opened a Scrivener file residing on a network disk. I added to it for about half an hour, then hit command-S, then quit Scrivener. After the program quit, I noticed that the network disk was no longer mounted on the desktop. Afraid that my file hadn’t saved properly, I re-mounted the network disk and opened the file. There was nothing of the past half-hour’s work there—the file was exactly as it had been before I started writing.

My question: is this the intended behavior of Scrivener when it can’t locate the file during a save? Or is my system behaving abnormally? It seems to me that it would be better to prompt the user to locate the original file, or at least to give a warning before quitting the application, instead of acting as though it saved properly.


The saving behaviour changes a little in the next version, but I would strongly recommend against working off network disks for Scrivener files, simply because they are not like regular files but are instead packages, meaning that all of the data is never held in your computer’s memory at any one time. Only the files currently in use are read from the package; thus, if the network disk went away, Scrivener would not be able to save the project elsewhere as it would only have part of it in memory.

Adobe also recommends this as well KB. working directly off of Networked files can cause problems and sometimes file corruption in many applications. Best to copy to HD work on the file then copy back to Server.

Hmmm… I see there are other problems too. If the disk is unmounted, then remounted, Scrivener won’t save the file, even though it’s updated, I’m guessing this is because the network disk’s name gets a higher number every time it’s remounted.

I’ll try to use the file on a local disk instead, and wait for any potential fixes in the next version.

But in any case, a warning dialog would be helpful in cases where it fails to save properly (to give the user the opportunity to copy the text to the clipboard before losing it). Other solutions would be to prompt the user to locate the package (ideal), or simply dump any text it still has in memory into a text file on the desktop.

SCR auto saves about every 2 seconds (by default) so ⌘+s is actually kinda pointless sort of…

A thing that I do as habit is I use the “Backup To” option as the last thing I do before shutting down for the night. That way I have a fresh full backup stored on another computer (network server) just in case something goes wrong with the computer I use to write on and the one that stores my original files. It is actually quite fast and not very bothersome to do as a last thing to do before quitting. Helps me sleep at night even though I do back up my whole HD I just like keeping another copy that I manually did on the networked drive (And also a copy on my Flash Drive. I know I may seem paranoid.)

Ok, lets talk network file systems and how OS/apps manage files.

The OS and app reference files via what called called a file handles. This handle is supposed to represent a disk location and for networked file systems this location is "mapped" by a kernel driver. Because networks are SLOW compared to local disks, the driver and sometimes the app will read as much of the file into buffer as it can. This is where the fun begins...

If for some reason the actual drive is no longer available then you will keep working with the cached version. Saves can be marked in the cache (called dirtying the cache) telling the OS to write back to disk at the first chance possible. But the disk is gone!!! So you, the enduser, reconnect to the drive. Only one problem… the original map is still in kernel space being used for the cached file. This means that the OS allocates a new map and your file is not able to be written to disk.

There are multiple types of “network” file systems. Each uses different methods of communications. Those communications are dramatically different when it comes to reliability for certain tasks. for example a protocol like SMB (windows) is pretty good for reading, but not all that great for writing. NFS is an excellent read/write system, but requires significant client configuration. Appletalk is… interesting.

So if you want to use network drive you need to make sure you use a protocol that will support your connection method. SMB and NFS are the most common for Unix and Unix like systems (OSX is a BSD derivative which is in turn Unix like).

SMB is generally Ok for large reads, and occasional writes. it is simple to set up but can have unusual disconnects. SMB originated with Microsoft and is geared towards the expected needs of that OS. I would recommend this protocol for general light usage.

NFS is the daddy of all network file systems. As a mater of fact NFS is Network File System. while not bullet proof it is the industry standard. We use it for everything from large, multi terabyte DB files to web server document roots, to workgroup collaboration areas. OSX supports it but if you want to use it you need to know what you are doing.

What should you do? Always work from a local copy, and use the network share as a back up location. Period (yes there are exceptions but let’s not muddy the waters here). This will ensure that all writes are successful, and provide you a backup copy in case the end of the word comes and your system dies.

Scrivener relies on the OS X file system, so if that doesn’t tell Scrivener that there is a problem then there is no way for Scrivener to react to it. There isn’t really anything I can do to “fix” this. You should be receiving a “There was a problem saving” message, and if you are not that is because OS X is not telling Scrivener that there is a problem. So I’m afraid there are no particular fixes for this in the pipeline, although Scrivener does rely a bit better on the standard OS X saving infrastructure in the next version. I’m not sure that will make much of a difference in this case, though.

Yeah, no message at all. Thanks for the help!


Ok once I started gettings errors from a network save I looked here and saw warnings … have now copied and working from project on local file … problem remains … and forced to do save as backups, boring … realise it’s an OS issue, but can I fix now I’m working locally?

Could be inherited permission problems inside the SCR PKG?

Doing a save AS and then working off the Saved As File does that get rid of the problems?

Wock - thanks for the reply. I was doing this at the office and have now come home and the copy on my desktop seems to be working ok - though a saved backup turned out to be empty!! Are you suggesting that I should check permissions on the package? how/what should they be?

No I was wondering if it was a networked file if it had inherited the permissions of the network drive/device instead of your Computer/Client.

If you do a Save as it will create a copy that should have the permissions of your Computer. (In theory I think) and then when you do a backup from the file on your HD (the saved as version) everything should be fine.

SImply put work off your local HD. Make a backup from the saved as and check it to see if all the data is there.

Just doing a SAVE AS and then using the SAVED AS file instead of the original should fix any permission problems.


If that makes any sense?