Uninstalling brew-cask-installed mosh removes hundreds of symlinks in /usr/ #2650
Comments
|
Hi! I'm incredibly sorry this happened to you, but glad that you turned it into a very useful report! I had the same problem when uninstalling That was the impetus behind a series of failsafes added in PRs #2595, #2623, #2613. And @vmrob has now joined in this effort with #2624. Only one of those PRs is merged so far. If you can help with reviewing the pending ones, please do so. Those patches are essential for making sure Anyone else who has a similar problem on uninstall -- please post the relevant package name in this issue! Also, I didn't really want to wreak havoc on my machine twice, so I never duplicated the uninstall bug. If anyone has OS X virtualized, you could help us with this important issue. |
ghost
assigned 
|
Wow @rolandwalker, how funny you should explicitly mention me and virtualization, because I actually just happened to have a virtualized Mavericks install! I can go ahead and test/verify this behavior right now. |
|
@vmrob I realized what the bug is here, at least one of them, & I can patch it tonight/tmw. But if you are taking requests, a helpful piece of knowledge for adding a second failsafe would be the output of the following in a fresh VM find /Library /System/Library -maxdepth 1 -type d |
|
I can confirm this behavior on a fresh Mavericks install. |
|
As requested: https://gist.github.com/vmrob/8657231 |
This safety feature addresses Homebrew#2650 somewhat indirectly. A list of system directories is defined. When the uninstall process encounters a "system directory" it does not touch that directory at all - no chmod on that dir - no search for broken symlinks in that dir - no cleanup of .DS_Store files in that dir Explictly listed files from a pkg receipts are not affected by this change. Individual files will still be removed, even if those files are in a special "system directory"
Fixes Homebrew#2650 (although there is more work to be done). The issue is that path.readlink.exist? returned false for all relative links, because readlink reads relative to the current working directory. This caused relative symlinks such as /usr/bin/tar to be deleted, because package mosh identified /usr/bin as one of its container directories. The simplest fix is not to use readlink at all, because path.exist? will tell us what we want to know, independent of current dir.
|
@wallacewinfrey this issue automatically closed itself because I merged a relevant fix into the master branch. However, the fix won't propagate out to you yet. First we have to cut a new release of the code, then you will have to run |
|
@wallacewinfrey I reviewed your list of delete commands and compared with a clean VM courtesy of @vmrob. Below is a gist for a shell script which can replace most of your broken symlinks. Inside the script are comments for those cases that cannot be repaired by running the script. I realize you may have already finished your repairs, but this will be left up in case anyone else needs it. |
|
This bug is resolved for all users as of release v0.28.0. Everyone is advised to |
Today I had an alarming experience installing mosh ( bfcb76a )
I ran:
then decided to uninstall it and ran:
After running the uninstaller, the output of which appeared normal, I noticed that /usr/bin/tar was missing. A quick check into /var/log/system.log revealed that the uninstaller process had actually removed hundreds of symlinks from /usr/
Here's a gist of the output demonstrating the installation/uninstallation and relevant entries from /var/log/syslog. It is preceded by my zsh history file entries showing the commands as executed.
I suppose it's possible that some other process decided to intervene at this exact point and time, and I've not had the time to reconstruct the actual sequence of events leading to this issue (too busy trying to rebuild my filesystem) but given the timestamps, the unknown TTY in the sudo output, and the fact that the brew-cask version of Mosh inexplicably requires the use of sudo (the homebrew install of mosh has no such requirement), I'm inclined to believe that it was an unfortunate combination of brew-cask, the Mosh formula, and my own ignorance for believing that the use of sudo was necessary.
The text was updated successfully, but these errors were encountered: