| Hard link issue with OS X distro: Please implement this simple fix | Mike Bombich | 22/05/15 07:51 | Hi, I develop backup software for OS X and have recently received several reports from Anaconda users about problems creating a couple hard links in the anaconda folder, e.g.: hard_link_one: link "Users/apple/anaconda/pkgs/launcher-1.0.0-2/launcherapp/Contents/PkgInfo" => Users/apple/anaconda/Launcher.app/Contents/PkgInfo failed: Operation not permitted (1) hard_link_one: link "Users/apple/anaconda/pkgs/launcher-1.0.0-2/launcherapp/Contents/Resources/empty.lproj" => Users/apple/anaconda/Launcher.app/Contents/Resources/empty.lproj failed: Operation not permitted (1) Likewise, if you attempt to copy the anaconda folder in the Finder, it will fail with an error indicating that you don't have access to all items (which is an incorrect translation of "Operation not permitted"). After some research, I discovered why this happens. It's easy to reproduce this same sort of error with these simple steps on a Yosemite system (this does not affect Mavericks): mkdir -p /tmp/test.app/Contents touch /tmp/test.app/Contents/PkgInfo mkdir -p /tmp/testapp/Contents ln /tmp/test.app/Contents/PkgInfo /tmp/testapp/Contents/PkgInfo That ln call fails with "Operation not permitted". This turns out to be an issue specific to *.app/Contents/PkgInfo and *.app/Contents/Resources/*.lproj files. OS X does not want to permit the creation of a hard link between one of these items in an application bundle to another file in a non-application-bundle folder. I was unable to find an explanation for this behavior in Apple's documentation, nor in the source code for HFS or the OS X kernel. The Anaconda installer manages to create this kind of "illegal" setup on the source with a workaround, e.g.: mkdir -p /tmp/test.app/Contents touch /tmp/test.app/Contents/PkgInfo.tmp mkdir -p /tmp/testapp/Contents ln /tmp/test.app/Contents/PkgInfo.tmp /tmp/testapp/Contents/PkgInfo.tmp mv /tmp/test.app/Contents/PkgInfo.tmp /tmp/test.app/Contents/PkgInfo I'm not suggesting that this is deliberate, just explaining how the invalid scenario could come about. I'm making the following suggestion to my users to work around the problem for now (and indicating it here for other users that might find it useful): 1. Copy /Users/yourname/anaconda/Launcher.app to some other volume (e.g. your backup volume) 2. Remove the /Users/yourname/anaconda/Launcher.app item from the source 3. Copy the Launcher.app item from the backup back to the anaconda folder in your home folder This simple procedure will sever the hard links between the Launcher.app item and the pkgs/launcher-1.0.0-2/launcherapp folder, so subsequent attempts to copy both items will succeed. ***** My request to the folks at Continuum, however, is to address this problem at the source by making one of two simple changes to the anaconda distribution: A. rename the "launcherapp" folder (at anaconda/pkgs/launcher-1.0.0-2/launcherapp) to "launcher.app". Having an ordinary .app extension will allow hard links to be created between the Launcher.app item and the launcher.app folder. Or B. Sever the hard links between the Launcher.app item and the launcherapp folder. "Launcher.app" is only 236KB -- a drop in the bucket compared to the 293MB distribution package. I don't fully understand the intricacies of the Anaconda distribution, so I'm not sure which of those is more appropriate. With either one of these changes, though, users will be able to copy the anaconda folder or back it up without issue on OS X Yosemite. Thanks, Mike Bombich Software, Inc. |
| Re: [Anaconda Support] Hard link issue with OS X distro: Please implement this simple fix | Ilan | 22/05/15 13:08 | Hello Mike, thanks for the feedback, and thanks for reaching out. We want to make Anaconda as compatible withand python.app packages have been a bit problematic from the beginning. Those packages have to be renamed (inside the conda package) because otherwise Mac OS X will treat them in a special way which was creating problems for our graphical .pkg installer. Therefore we currently apply the following renaming during the install process of the package: $ mv $PREFIX/launcherapp $PREFIX/Launcher.app Changing this command to: $ cp -r $PREFIX/launcherapp $PREFIX/Launcher.app $ rm -rf $PREFIX/launcherapp will break the hard links, and should solve the problem with the backup software you are working on. We will try to reproduce the problem, as well as make sure that it gets fixed by the next Anaconda 2.3 release, which is schedules for early July. Regards Ilan -- |
| Re: [Anaconda Support] Hard link issue with OS X distro: Please implement this simple fix | Tom Loredo | 14/06/15 11:35 | As both a heavy (academic) Anaconda user (I use it for research and in the classroom), and a developer who is fairly diligent about backups, I'd like to highlight that this is a serious bug. I hope a fix is high on Continuum's priority list. Also, I think something about this needs to be clarified in a readily visible place. I just wasted an hour of my time trying to figure out how to handle it. It showed up after I did a clean upgrade to Yosemite, migrating my previous installation, which copied Anaconda. A subsequent backup attempt failed. I thought the backup failure Mike describes was due to an Apple migration issue, and so I deleted and attempted a re-install of Anaconda, which in fact was both unnecessary and not helpful. To clarify: Although Mac users have easy backup capability via Time Machine (which I presume is unaffected by this), Time Machine does not produce full, bootable backups of Mac partitions. For that purpose, 3rd party apps are needed. Mike is not developing new Mac backup software (your response suggests you may have interpreted his message as indicating this). Rather, he's the developer of CarbonCopyCloner, one of the two leading backup tools for OS X: Drive-cloning utilities: The best Mac apps for making a bootable backup I use a competing product, SuperDuper!, which has the same issue. So this problem cripples the two most highly recommended and most-used OS X backup strategies, which I feel should be considered a serious issue. It really should be mentioned prominently someplace where users upgrading to Yosemite can easily discover it. Personally, I think it merits a mention in your regular email to users. FYI, I've copied the SuperDuper! error log, hoping it will help ensure a fix works for SuperDuper! as well as CCC. Apparently SuperDuper! is having problems with pythonapp rather than launcherapp (it may not have reached launcherapp before failing). -Tom SuperDuper! log: | 04:47:01 AM | Info | /anaconda | 04:49:42 AM | Info | Error creating hard link /Volumes/RMBP System 10.10/anaconda/pkgs/python.app-1.2-py27_3/pythonapp/Contents/PkgInfo to /Volumes/RMBP System 10.10/anaconda/python.app/Contents/PkgInfo for inode (null) | 04:49:42 AM | Error | SDCopy: Error creating hard link /Volumes/RMBP System 10.10/anaconda/pkgs/python.app-1.2-py27_3/pythonapp/Contents/PkgInfo to /Volumes/RMBP System 10.10/anaconda/python.app/Contents/PkgInfo for inode (null) | 04:49:42 AM | Error | : Operation not permitted |
| Re: [Anaconda Support] Hard link issue with OS X distro: Please implement this simple fix | Tom Loredo | 14/06/15 12:59 | FYI: I went ahead and deleted my prior Anaconda installation (migrated from Mavericks, and updated just prior to the migration), and installed the current one: $ conda -V conda 3.10.0 I then ran SuperDuper! again, and the backup completed with no problem. Perhaps Continuum has already pushed the fix to the current Anaconda distribution. But since I'd just updated conda and Anaconda before the migration, perhaps this was a migration issue. -Tom |
| Re: [Anaconda Support] Hard link issue with OS X distro: Please implement this simple fix | fpere...@gmail.com | 01/10/15 18:59 | Hi all, I just wanted to pitch in on this issue, because after wasting some time looking for a solution to odd error messages in my rsync-based backups, I ended up finding this thread. Much to my surprise (at first I thought the problem was something fairly generic), the issue was indeed with these conda-specific files... Just to summarize again the point that Mike makes above, the minimal illustration of the problem is this: denali[~]> ln ~/usr/conda/envs/ipython-3/python.app/Contents/PkgInfo . ln: ./PkgInfo: Operation not permitted These PkgInfo (and the same for the Resources/*.lproj) files, for some bizarre, incomprehensible reason can't be hard-linked. And yet, the way Conda is installing them makes them appear to be hardlinked. In my case, I'm running a call between machines that uses `rsync -aH`, which tries to preserve hard links, and these cause it to error. I'm not really sure what's so special about those files, in my case I'm seeing the error with two of them: rsync: link "/Users/fperez/usr/conda/pkgs/python.app-1.2-py34_3/pythonapp/Contents/Resources/empty.lproj" => usr/conda/envs/ipython-3/python.app/Contents/Resources/empty.lproj failed: Operation not permitted (1) rsync: link "/Users/fperez/usr/conda/pkgs/python.app-1.2-py34_3/pythonapp/Contents/PkgInfo" => usr/conda/envs/ipython-3/python.app/Contents/PkgInfo failed: Operation not permitted (1) And the empty.lproj one is actually an empty file! So I have no idea why an empty file can't be hardlinked. But if the folks above, who are experts in the intricacies of HFS and backups on OS X don't know, I'm for sure not going to figure it out now :) I just wanted to provide an extra data point that the problem persists, and that it's present even for simple rsync-based backups, so I really hope Conda can switch to an alternative for these files that doesn't cause the issue. Probably the simplest way to test if you've come up with a solution that fixes the issue would be to: 1. Install some packages in an environment. 2. rsync the entire directory containing the environment with `rsync -aH` to a target empty location. If that succeeds without error, it means all hardlinks were correctly preserved. I *think* this should do it, though I might be missing something. For now, I guess I'll have to manually break those hardlinks with copies at the source so that rsync doesn't try to make them as hardlinks and my backups actually work... I hope you folks can fix this. Many thanks!! f |
| Re: [Anaconda Support] Hard link issue with OS X distro: Please implement this simple fix | Carlos Córdoba | 02/10/15 14:13 |
Hi Fernando,
Thanks for letting us know that this is still a problem. It seems a really hairy issue but I'll try to take a look at it when I have some time :-) Cheers, Carlos El 01/10/15 a las 20:59,
fpere...@gmail.com escribió:
-- |
| Re: [Anaconda Support] Hard link issue with OS X distro: Please implement this simple fix | Fernando Perez | 02/10/15 17:39 |
Thanks! BTW, upon re-reading the thread more carefully, I realized that Mike's original message did have a complete explanation of the problem, I just missed it in my first reading. Just in case anyone else got confused as well, the issue is that Apple prevents the hardlink when the source is in an app bundle and the destination outside an app bundle, that's all. Nothing to do with the size, type or content of the files. And that also explains why conda's workaround works, since it moves things around to a temporary non-bundle folder, where the hardlink restriction doesn't apply. Sorry for not reading more carefully on my first pass. Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail |
| Re: [Anaconda Support] Hard link issue with OS X distro: Please implement this simple fix | jip.d...@gmail.com | 23/11/15 14:39 | This issue has been fixed for me by uninstalling and reinstalling Anaconda. More here: https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/VsnnithlSxw Op zaterdag 3 oktober 2015 02:39:19 UTC+2 schreef Fernando Perez: |