Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the TidBITS Content Network for Apple consultants.

How to Fix Snow Leopard's Finder-Copying Bug

In "A Finder-Copying Bug in Snow Leopard" (10 November 2009), I reported the existence of a bug related to copying files in Snow Leopard, and explained how to see the bug in action. Basically, the bug arises when you attempt to copy a "troublesome file" from a Snow Leopard machine to another computer via File Sharing. I also provided specific instructions for reproducing the bug using an example troublesome file that anyone could download.

In the previous article I suggested that perhaps the troublesome file was always an application, but readers have supplied examples of other bundles that can also trigger the bug. So, a troublesome file is always a bundle, but not every bundle is troublesome. Then the question is: What, exactly, makes a troublesome bundle troublesome?

By comparing two very similar applications, one of which is troublesome and the other not, even though they have nearly identical internal structures, I have discovered that the answer involves Unix permissions on symlinks inside the bundle.

Here's a quick Unix refresher. A symlink is a file that points to another file (the other file can be a folder). Unix permissions specify whether a file can be read (r), written (w), or executed (x), and they specify each of those with regard to three categories of person: the user that owns the file, the members of the group that owns the file, and the rest of the world.

A troublesome file turns out to be a bundle containing a symlink that is itself marked as writable by the group or the rest of the world. Here's an example (generated by the ls -al command, with much of the information omitted):

lrwxrwxrwx /Applications/
-> Versions/Current/Growl

It's a symlink (that's what the initial "l" means), and it is readable, writable, and executable ("rwx") by the user (the first "rwx"), the group (the second "rwx"), and everyone else (the third "rwx").

In theory, permissions on a symlink should be more or less meaningless; a Unix system should ignore them. But apparently Snow Leopard does not ignore them, and therein lies the trouble. Here's what seems to be happening. The user tries to copy the bundle, so the Finder proceeds to copy the bundle's contents. The symlink is encountered before the file it points to. So the symlink is copied to the remote machine, and now the system sees (I'm guessing) that the symlink's permissions are unusual, and tries to copy those permissions onto the file it points to, also on the remote machine. But the file that the symlink points to has not yet been copied to the remote machine, so this attempt to set its permissions fails, and the Finder raises an error (-36).

If you'd like to know whether you have any potentially troublesome bundles, run this command in Terminal:

sudo find / -type l -perm +g+w -ls

You'll be asked for your password. After you give it (and press Return), go get a cup of coffee, because this command takes a long time while your entire hard drive is traversed. In the end, a list appears showing all files that are symlinks ("-type l") and also give write permissions to the group ("-perm +g+w"). The symlinks are each inside some bundle, so if you read the pathname backwards you can see what bundle it is. For example, the symlink listed in the example above is inside So, that copy of Interarchy constitutes a troublesome file, and cannot be copied to another machine using the Finder via File Sharing.

Both TidBITS Publisher Adam Engst and I tried the above command, and came up with a list of bundles that are troublesome on our respective machines. The list includes, on Adam's machine, Interarchy, Nisus Thesaurus, Quicksilver, and an iPhoto Library, and on my machine, a bunch of Omni applications, including OmniWeb, OmniDazzle, and others. Why our results don't match - why, for example, my copy of Interarchy has different permissions on its symlinks than Adam's - remains a mystery. But what is clear is that, in both our tests, the bundles that are ferreted out in this way are exactly the ones that trigger the Finder copying bug.

If you'd like to fix the problem, by changing the permissions on the symlinks within a bundle, so that bundle can be successfully Finder-copied via File Sharing, here's how to do it. In the Terminal, type:


Then type a space. Now drag the troublesome file from the Finder into the Terminal window; this causes the Terminal to enter the pathname of the bundle. For example, if at this point Adam were to drag Interarchy into the Terminal window, the Terminal would now read:

find /Applications/

Now continue typing, so that your command has this form:

find /Applications/ -type l -exec chmod -h go-w {} \;

At the end, press Return. The command means: Traverse down into Interarchy, looking for symlinks ("-type l"). When you find one, change the permissions ("-exec chmod") of the symlink itself ("-h") so that neither the group nor the rest of the world have write permission ("go-w"). I'm not going to explain the other stuff, but it's all essential, including the backslash before the semicolon. After running this command on a bundle, the bundle will still work fine, and it will no longer trigger the Finder-copying bug.


Backblaze is unlimited, unthrottled backup for Macs at $5/month.
Web access to files means your data is always available. Restore
by Mail allows you to recover files via a hard drive or USB.
Start your 15-day trial today! <>

Comments about How to Fix Snow Leopard's Finder-Copying Bug
(Comments are closed.)

Nice work, thanks. I might not have noticed this, it seems we don't use file sharing much anymore. We used to use it a lot in the old days, but most people would rather just email a file or two (majority of cases fit this) than to bother using file sharing or a server.

I particularly like the explanation of the terminal command, I hate when these show up on blogs etc... and they are not explained.
Other than the filesharing copy issue in Snow Leopard, is there any other drawback to leaving the permissions as is? I used your FIND command I and I found quite a few, including a few Apple applications.
Matt Neuburg  An apple icon for a TidBITS Staffer 2009-11-20 09:45
Very good question - we should probably amend the article to deal with this. The answer is decidedly no. I discovered the bug because I do a lot of file sharing copying, to synchronize two computers; many people have only one computer and will never encounter the problem.
cheerful  2009-11-20 23:58
I encountered such issues too as I, too, do lots of file sharing copying.
Matthew  2009-11-22 14:05
Run this as root:

cd /
mdfind "kMDItemContentTypeTree == **" -0
xargs -0 -J % -n 1 find % -type l -perm +g+w -exec chmod -h go-w {} \;

This will find all bundles (mdfind "kMDItemContentTypeTree == **"), separating each result with a null character ("-0"). This gets passed ("
") to xargs. It expects the null character (-0) separating the results. xargs executes the find command for each result ("-n 1") from mdfind, substituting the % sign in the find command ("-J %") with the result.
Peter Timofejew  2009-11-24 17:41
Unfortunately, this fix doesn't seem to work on iPhoto Library bundles for me.

I'm running Mac OS X Server (10.6.2), and it fails regardless of what the sym link permissions are. Which is unfortunate, as I was quite excited about finding Matt's article as it offered an explanation as to why Portable Home Directory syncing failed on iPhoto Libraries.

Interestingly, if I attempt the copy manually via the finder, wait until it fails, then copy over the remaining files within the bundle (using "Show contents" and selecting the internal files), it will complete, and the bundle seems to work fine on the server.

So, there is something definitely weird about the sym link, but unfortunately Matt's workaround seems to only work for client->client sharing, not client->server sharing (which will be the vast majority of users, so the workaround will work for most people).

Hopefully, Apple fixes this bug soon - it's not a killer, but I would like to sync my iPhoto libraries with the server.
OT as regards file copying but as related to symbolic link behavior:

I've had a longstanding issue with .textClipping files not previewing correctly in QuickLook when invoked by the spacebar. I noted at one site a developer explained his application's files where not previewing in QL because he had to "fix the symbolic link."

So this led me to wondering if QL has a bug as regards .textClipping flies on my system? If this seems a possibility, how to apply the ideas in Matt's article? To which package?

Note: Most all other files preview, but clippings, invoked by spacebar, display a generic icon, as in Leopard. Double clicking a clipping also previews clippings correctly.