error -36 when copying to a Windows/DOS formatted disk from Finder

Ever try copying files from a Mac to an SMB share? How about from a Mac to a local drive formatted as FAT 16 or 32? Many times you’ll get the error -36, or -1492 or some other nonsensical number, “An error occurred.” This problem was reported to affect only users of OS X 10.6.2, and fixed in the 10.6.3 update but alas, it still affects users of 10.6 all the way up to OS X 10.6.8.

Basically the numerical code is worthless. All it means is that “An error occurred, sorry. Try again.” The problem stems from DOS-type filesystems being unable to comprehend the “._” and “.DS_Store” files that a Mac will create ALL OVER THE PLACE.  To compound the problem, Finder is too dumb to ignore files it can’t copy and will just fail when the DOS formatted disk says “NO!” In Apple’s defense, the .DS_Store files are certainly not useless, to an HFS-type system. They keep metadata like window position, size, etc. The ._ files also contain metadata about the particular file, like creation time, extended attributes, etc. However, since Windows doesn’t understand this type of metadata, it would rather not have these things around, and will block copies from the Finder about half the time…

So in order to work around this, “best practice” is to compress the files into a .zip or .dmg archive before copying them to a non-HFS filesystem. In fact you should compress your Mac files any time you are unsure if they will be stored on an HFS filesystem or not.

But since compressing files before copying is not always the first thing on peoples’ minds, many different types of utilities also have been created that do one thing or another to clean up these ._ and/or .DS_Store files: DS_Store Cleaner being one of them that is used at my office. There is also the “dot_clean” terminal command that is built into the Mac OS. To use this command, go into the terminal, and simply type

dot_clean --keep=dotbar /Path/to/file/

This will recursively merge any ._* type files with their same-named counterparts, preferring the information stored in the ._ file over the same information that may or may not be kept in the actual data file. You can use the -m option to just remove them rather than merge them if you want.

This type of command can easily be made into an Applescript droplet, perhaps also combined with the

find "/Path/to/file" -type f -name ".DS_Store" -delete

command to remove pesky .DS_Store files in one fell swoop. Don’t worry, removing these “.” files will not harm the copy to a non-HFS filesystem since it ignores these files anyway.

Another option to help avoid this issue with copying is to use the terminal to copy the file, ala

rsync -avE /Path/to/source /Path/to/destination

This will use Unix to copy the files recursively, preserving permissions and ownership with the -E option, showing the files being copied with the -v option, and creating an exact duplicate of what you want to copy with the -a option. It has the added benefit of being faster as well as ignoring a file it can’t copy and moving on to the next rather than simply failing. The only caveat is that the file(s) being copied are beholden to Unix filesystem rules, so illegal characters, string length, etc in the Unix world will apply here and cause the file to be skipped. If a FOLDER breaks these rules, then that entire folder is skipped, and that may result in a lot of data failing to copy, even if the data inside that folder does not violate Unix file system rules.

About this entry