A Finder-Copying Bug in Snow Leopard
Here’s a bug in Snow Leopard that I’ve isolated. I haven’t seen it reported elsewhere (not in precisely this form, at least), so I’ll describe it and let you reproduce it for yourself. You’ll need two computers, one of them running Snow Leopard.
Preparation — Let’s call the machines A and B. Machine A must be running Snow Leopard. I don’t much care what Machine B is running; I’ve tested with Machine B running either Leopard or Snow Leopard, and it makes no difference. Machine B must have File Sharing turned on. Once that’s done, you will work entirely at Machine A.
Performance — To see the bug, perform (on Machine A) the following steps:
- Mount Machine B on Machine A (via File Sharing). So, you’re still working at Machine A, but in Machine A’s Finder you can see Machine B’s folders.
- Download The Omni Group’s OmniDazzle, using this link. (The bug likely has nothing to do with Omni’s applications per se, but many of them demonstrate the bug, so I’ve picked a small one that does.)
- If it hasn’t automatically opened and mounted, open the downloaded .dmg file. Accept the legal agreement. You are now looking at the OmniDazzle application on the mounted OmniDazzle volume.
- Drag the OmniDazzle application from the mounted OmniDazzle volume to a folder of Machine B to copy it. You can’t do it; the Finder puts up a dialog reporting Error -36. That’s the bug.
Further Details — The bug has nothing to do with the fact that the OmniDazzle application is initially on a mounted .dmg image. I just had you start with the mounted .dmg image for the sake of simplicity. If you copy OmniDazzle to Machine A (say, to the Desktop) and then try to copy that copy to Machine B, you’ll still get the bug.
The bug is unidirectional. You can’t copy OmniDazzle from Machine A to Machine B, but you can copy it from Machine B to Machine A (assuming you are working at Machine A).
The bug seems to affect only applications, but I’m not entirely sure about that. Moreover, it doesn’t affect every application; as I said before, it affects most of Omni’s applications, so I’m using one of them for demonstration purposes.
The bug has to do with File Sharing. If Machine A and Machine B are connected in some other way – for example, if Machine B is mounted in FireWire Target Mode on Machine A – there’s no problem.
The bug has to do with Snow Leopard. If Machine A is running Leopard, there’s no problem.
The bug has to do with the Finder. If you perform the copy using the Unix cp command in the Terminal, the copy succeeds. (A sample Terminal command is provided below; don’t do this, though, unless you already understand cp, because the syntax here is tricky and there is some danger if you make a mistake.)
cp -a /Volumes/OmniDazzle/OmniDazzle.app /Volumes/mattleopard/Desktop/
When using cp in this way, some error messages do appear in the Terminal, but they don’t seem to be fatal: the whole application is copied, and will run successfully on the remote machine. In fact, I wonder whether these error messages have something to do with the Finder’s error message. Perhaps some reader who understands extended attributes and symbolic links better than I do can explain what’s going on here.
Thanks for documenting Matt. I had noticed this but didn't give it much thought--just dragged the .dmg to Machine B rather than its contents. Have you lodged it with Apple?
Yes, I have. - Sure, obviously there are workarounds, but it's still a bug!
Perhaps it is related to this issue
I reported this Bug to Apple a few weeks ago.
The problem appears to be with the soft links in the application. All the errors in the cp -a command are related to missing files, that are targets of soft links.
When you copy the app in the finder, parts of the directory structure are copied, including a soft link, but not its target. My guess is that the finder does the same thing as cp -a, but checks for errors and gives up when it sees the errors that you see in Terminal.
If the targets were copied before the links, these problems should not occur.
When using cp's "-a" option, errors are ignored.
"It's not a bug, it is a security feature."
What gives you the right to transfer an app from one machine to another without authorization of the license from the creator of the app? If you have the EULA permission to transfer the software from one machine to the other, then maybe it will work, but the security feature is in place in Snow Leopard to keep you from making that faux paux.
I have my machine set up so I can't even move a file off my desktop to my hard drive without authentication first. It is a pain, but I accepted that level of security in order to protect my system.
Also, are you using FileVault by chance? (I'm not yet.)
Sorry, this is wrong - it IS a bug. If Apple really wanted to keep you from copying applications, they would have provided a more useful error message than "Error -36". And if Apple really wanted to keep you from copying applications, they would have plugged other obvious workarounds such as copying applications to a USB drive.
this is silly. Apple can't enforce all the different EULA's in software (nor is it their job to do so for other companies).
This workflow is not an EULA violation in most situtionat. Machine A - downloads, opens DMG, installs to Machine B. It is never installed on Machine A so no EULA violation.
And this is a common workflow in a company where there is a central authority to install software and users must contact that authority to get new software (i.e. software license enforcement.)
This is not an intentional security feature (or it would happen with all apps, and with better explanations.)
Matt, I can reproduce this bug exactly. It's been infuriating since I discovered it a few days ago.
Have you isolated it to a protocol? Does it do it with AFP and SMB/CIFS?
There has been a thread on Apple Support Discussions about this: http://discussions.apple.com/thread.jspa?threadID=2139000&start=0&tstart=0 - unfortunately Apple hasn't addressed this, even in 10.6.2. It appears to be an issue with application bundles that contain internal links. One workaround is to compress (zip) the bundle and copy that to the networked drive.
When I try to copy a series of jpeg files from my Mac, snow Leopard running, to a windows machine, I get the same error. Funny is that when copying them one by one, despite the error message they all copy perfectly.
Is there any chance that maybe machine B was set to not allow any copying from outside viewers such as machine A. I know in file permissions you can set it to where "everyone" is not allowed to read or write. For me my hard drive automatically has it set to where "everyone" can only read but not write. So could that be the issue instead of it being a bug?
This errorcode 36 with Finder is also applicable when you want to copy/upload files to a MS SharePoint Document Library. This used to be no problem but since SL it is not working anymore.
Well I don't see it. I did this process, copying 70 apps from Machine A (10.6.2, Intel) to B (10.5.8, G5) via Airport+enet to a folder on a user's Desktop in Machine B. All copied and worked without error. None of these were Omni apps, however.
It's not just any file, it's applications that rely on some sort of symbolic link or the like.
This bug has been frustrating me since I first upgraded to Snow Leopard back in October. It actually seems to effect not just applications but any group of files that are packaged as a bundle (thus appearing as an individual file to the average user) which in turn contains certain types of symbolic links. For example I can reproduce this error when trying to copy my Parallels Virtual Machine files from my Parallels folder on my desktop machine to my notebook.
I had the same problem when trying to copy my iPhoto09 library from one Mac to another. I circumvented the problem by using an external hard drive.
If you use cp, use "cp -R /path/to/app" instead.
Ditto command will work well for copying