MacPorts 1.8.0 deletes ${prefix} if it is a symlink

[ryandesign@…]

If you install MacPorts 1.8.0 in a certain prefix, say /a, and then move it some place else, say /b, and make a symlink at /a pointing to /b, then "port install" works ok, but "port deactivate" and "port uninstall" will both remove the symlink at /a, thus breaking the installation. This did not happen with 1.7.1. This bug was  reported on the mailing list by Randal L. Schwartz.

Attached is a script I wrote to test for the problem. It will download MacPorts base trunk to /tmp/mpbase, download the portindex and zlib portfile to /tmp/mpdports, and compile MacPorts and install it in the prefix /tmp/mpone. It will move /tmp/mpone to /tmp/mptwo and create a symlink at /tmp/mpone pointing to /tmp/mptwo. It will install zlib, downloading the zlib distfile in /tmp/mpdistfiles, and then deactivate zlib. It will state whether /tmp/mpone still exists, and then delete /tmp/mpone and /tmp/mptwo.

As an argument to the script, you can specify the revision of trunk you want to test. Testing on Leopard I get:

$ sudo ./symlinkbug.sh 55000
[snip]
Bug present in base rev 55000: /tmp/mpone is gone
$ sudo ./symlinkbug.sh 50000
[snip]
Bug absent in base rev 50000: /tmp/mpone exists
$

Now we just need to do some bisecting and figure out which revision between 50000 and 55000 caused the problem. I suggest first looking at the revision that merged in the GSoC '08 privileges code, and the revisions that changed from calling system executables to calling Tcl functions.

[ryandesign@…]

This isn't quite right yet: my test was tainted by the fact I chose to put things in /tmp, which is itself a symlink. Running the test script can cause /tmp to be deleted. Please wait until I have fixed the script.

[devans@…]

Rough patch

[devans@…]

I have had the same problem on my system. I was running out of disk space on my main disk so moved /opt/local to a second disk with a link link this

/opt/local  -> /Volumes/disk2/opt/local

Note that any symlink that appears in the 'directory' portion of a path that is being deactivated or uninstalled will be deleted.

Attached is a patch that fixes the problem for me although someone who knows more about MacPorts could probably do it better.

[jmr@…]

See also #13707.

[and.damore@…]

Cc Me!

[alakazam@…]

Cc Me!

[jmr@…]

behaviour on 10.6

[jmr@…]

The script tells me that the bug is absent in trunk on my 10.6 system. Output attached. Can someone attach debug output from an affected system?

[ryandesign@…]

If you ran the script as is, please check whether it has deleted your /tmp symlink and recreated a directory /tmp. If so, delete the directory /tmp and replace it with a symlink to /private/tmp. I will try to attach a revised script that does not use /tmp.

[dh@…]

Cc Me!

[ryandesign@…]

Has duplicate #21297.

[jmr@…]

Replying to ryandesign@…:

If you ran the script as is, please check whether it has deleted your /tmp symlink and recreated a directory /tmp.

Nope, /tmp is still fine.

[dh@…]

Here is the decision to destroy /opt revealed in the -d output ...

DEBUG: /opt/local/bin is not empty
DEBUG: /opt/local is not empty
DEBUG: deactivating link: /opt
DEBUG: / is not empty

[jmr@…]

So apparently file normalize is broken on the affected systems. Interestingly, it works correctly even in tclsh8.4 on 10.6. So r49347 is probably where the regression appeared. Unfortunately compat filenormalize was broken in other ways.

[ryandesign@…]

Replying to jmr@…:

Interestingly, it works correctly even in tclsh8.4 on 10.6.

All my testing has been on 10.6, where I was able to observe the issue.

[jmr@…]

Replying to ryandesign@…:

All my testing has been on 10.6, where I was able to observe the issue.

Well, I'm unable to explain that. The behaviour I'm seeing is exactly consistent with a bug that was fixed in Tcl 8.4.10 or so (Leopard and Tiger ship with 8.4.7). In any case, the changes in r57436 and r57441 seem to fix this on Leopard.

[jmr@…]

Would anyone care to confirm or deny the effectiveness of the attempted fix?

[mike@…]

Cc Me!

[mike@…]

Have not tested patch, but can confirm bug exhibited if macports is installed in $HOME, /Users is a symlink, OS X 10.5, MacPorts 1.8.0 and tclsh 8.4.

e.g. of buggy behaviour:

$ port uninstall bzip2
--->  Deactivating bzip2 @1.0.5_2+darwin
Error: port uninstall failed: error deleting "/Users": permission denied

[ketanpadegaonkar+macports@…]

Cc Me!

[ketanpadegaonkar+macports@…]

Replying to devans@…:

Attached is a patch that fixes the problem for me although someone who knows more about MacPorts could probably do it better.

I've patched my copy of macports with the patch. This patch has worked fine for me, so a +1 if that helps move this ahead.

[jmr@…]

Replying to ketanpadegaonkar+macports@…:

I've patched my copy of macports with the patch. This patch has worked fine for me, so a +1 if that helps move this ahead.

The patch attached to this ticket or the one I committed to trunk?

[ketanpadegaonkar+macports@…]

Replying to jmr@…:

The patch attached to this ticket or the one I committed to trunk?

I've used the the patch attached to this ticket. I did not want to compile the change sets that were checked in into svn.

[jmr@…]

Back to waiting for someone to test it then...

[alakazam@…]

Trunk no longer removes my symlinks (I'm using one to version /opt/local/etc, and it hasn't been reset for a couple of days now).