Finder error -36


I’ve been syncing my Scrivener file between my desktop & my laptop with a thumb drive. I type and save normally on one & then cut and paste the .scriv folder to the thumb drive, then move it to the document folder on the other machine, replacing (overwriting) the existing file when prompted.

This has worked seamlessly until last night when I tried to move the .scriv file on my laptop to the thumbdrive. I got the error message Error code – 36 that said something to the effect that there was data that couldn’t be read or written.

So I manually entered the changes on my desktop & was able to save those changes to the thumbdrive so I’m guessing it’s not the thumbdrive?

I’m using Snow Leopard 10.6.2 on both computers. No errors at all on the desktop. And I’m able to copy Word files on the thumbdrive on my laptop…just not my .scriv files.

Any suggestions??

Patti, I’m not a geek, so won’t attempt to explain what error -36 is, but do just allow me to re-iterate a point that has been made in many threads. A Scrivener file is not actually a file, it’s a package, a special kind of folder full of potentially thousands of little files … every document you see in your binder is a separate file within that folder. The best and safest way to move a Scrivener project from one machine to another is to choose “Backup project to” from the file menu — or press Shift-Cmd-S — click the “Backup as ZIP” box to tick it, and then copy that file across and un-zip it on the other machine. A .zip is a single, compressed file, not a folder full of hundreds of files, copying which can be a disaster waiting to happen.

And in my experience, thumb drives are not terribly reliable.


Okay, I had come on to report the same error, and saw I was not the only one with it. While I sympathize, Patti, thank for you making me not feel so stupid…:slight_smile:

It reached a point last night where I encountered the “Error -36” message one time too many. Some research online showed it happens a lot in Snow Leopard, so I said all the appropriate words (the ones my grandmother said I shouldn’t say) and got out the Install software and spent today re-installing Leopard, going back a step. Things were going along nicely, until two minutes ago. If I go into the folder where I have the .SCRIV file and drag it to the thumb drive (I’m alternating between a Mac Mini and Macbook Pro, so this is kind of important for me to keep same copies on both), it copies just fine. Trying to BACKUP PROJECT within Scrivener, and I got “Project cannot be backed up”. I tried three different USB drives with the same result. I can COPY to all three just fine, but BACKUP PROJECT fails me every single time.

I don’t know what’s going on, but I’m sure Keith is already aware of it (as I said, now I don’t feel stupid) and will hopefully figure this out.


Because this is a file system problem and not a Scrivener one, I’m afraid I don’t think there is anything for me to figure out, sorry. :frowning: The backup failing only means one thing - your file system is telling Scrivener that it can’t back up. When Scrivener backs up, it does one of two things - if you have the zip option selected, it calls through to the shell’s zip command to create a zipped up version of the project; if not, it uses file system commands to create a copy. In either case, the code is all handled at the OS-level, and if it fails it isn’t because Scrivener is doing anything weird, but because your file system has told Scrivener that it can’t copy or zip up the project. Unfortunately the file system doesn’t tell Scrivener anything more than that. It’s a yes or no thing - Scrivener says to the OS X file system, “Hey, copy this file using whatever internal methods you use for these things.” And then the file system says back either yes or no, with no further explanation. So if Scrivener is refusing to back up, then my guess is that whatever on your file system was causing the Error 36 is causing the same problem. Unfortunately, because it’s something specific to your system, and because the file system refuses to give further information, it is difficult for me to guess the issue.

The first thing I would try is checking the permissions on the project. Then I would check that you were trying to backup to the same location you were copying to, and that you can copy files to the location you were trying to backup to. Then I would try repairing permissions and running disk utility.

All the best,

First off, do not backup to directly to the USB drive. That is not the best way to do this. Backup to the local drive then copy the backup to the USB. Make sure you eject the USB before removing it from the system.

The best thing to try here is removing the offending file from the USB drive. Then make a fresh copy on the Snow Leopard machine. That is likely to clear it up. If not try copying to the UBS root (window that opens when you double click the drive icon). If that fails you will want to reformat the drive. back the USB drive up first.

As Mr X says, you will have better luck with backup to (use the local drive not the USB drive as the destination).

Error 36, by the way is an I/O error, which is often hardware related. If it only happens with the thumbdrive, it could have damaged sectors or some other problem (you usually see the error on CD-ROMs and DVDs, as they most prone to surface damage). This is probably less serious than it sounds, though you should back it up, reformat it, and copy everything back. Formatting it will create a table of error spots and skip them in the future (FAT16 format might not do this though?). If you still get the same error type after formatting, it’s probably time to replace the thumb drive. It might have an abraded contact, minor moisture damage, or bad interface circuitry.

If you routinely get this error all of the time whether or not the thumbdrive is plugged in, you probably ought to make sure your system disk is backed up, yesterday.

I suspect it’s the thumb drive. It’s really a Windows device that Macs can use but don’t really love. The file structure on the drive is corrupt.

Plug in the drive, open Disk Utility and format the USB drive as a MAC OS extended journaling. Save away and I think you’ll be much happier.

All of a sudden, same problem here (OS 10.6.2) after years of backing up to USB flash drives.

Here’s what I can add:

  • I see the problem (i.e. -36 error when I try to drag copy the Scrivener project file) on 2 separate USB drives.

  • When a drag copy of my Scrivener project fails, the console system log gives the following error:
    Possible unresolved transaction race -104/(CrossRoads.scriv,(null))

  • I can use Scrivener’s backup function to ZIP a copy of the project to the USB drive.

  • If I try to ZIP the project using the Finder compress function, the progress window bar graph fills to about 90% complete and stays there until I cancel the compress.

  • If I reformat the USB drive as Mac OS Extended (journaled), all problems go away and I can copy the project to the drive.

  • If I reformat the the same USB drive back to MS-DOS (Fat), the problem returns.

Does it do this with multiple devices? It might just be as I originally suspected and the drive itself is faulty and FAT16 is not robust enough to skip past the bad sectors. Do you need FAT16 (Windows support?)

As noted in my first bullet, I can reproduce this problem on 2 separate USB thumb drives.

As an experiment, I tried opening the Scrivener package and copying the individual blocks of files, to see if I could learn anything about the file(s) causing the error. All failures occurred during the attempt to copy a TXT file, and the error is “rolling” in nature, i.e., eliminate the problem file from the to-copy group and another file takes its place as trigger. This (and the fact that ZIPing prior to copying the project works) suggests the problem has nothing to do with the content of the files.

As suggested by animus earlier in the thread, reformatting the thumb drive to Mac OS Extended (Journaled) fixes the problem and (in my case) results in a comparatively faster copy process to that drive.

More than likely the problem is with the MS format of the USB drives. [lots of techno-babble about journaling hiding issues and how everything MS does should be suspected as the source of all that is bad/wrong in the world deleted]

As an interesting test, what happens if you take that backup file, unzip it to a new folder, then copy the project to the USB drive?

I haven’t seen an good explanation or work around for this problem here, but since I have started (post Snow Leopard upgrade) to have it, here’s one I discovered on the macosxhints forum:

Not exactly an elegant solution, but I’ve tried the workaround with .scriv files (which are essentially folders pretending to be files) and it succeeds. Since the workaround works, it seems likely that the explanation is reasonably close to correct. 10.6.3 is supposed to be out sometime relatively soon and, hopefully, it will include a fix for this bug.