Doesn't protect symbolic links
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Safe-rm |
Fix Released
|
Low
|
François Marier |
Bug Description
In version 0.6 a bug was fixed (and presumably the not -l flag added to the check) regarding symbolic links.
I believe it should protect symbolic links if that was the full path specified under the principle of least astonishment.
Take this scenario:
OS X symlinks /etc, /tmp/ and /var to directories residing in /private
Given the default blacklist includes /var you would expect a sudo rm -rf /var to skip the file. But as it's a symlink, safe-rm will give it a pass and the symlink is deleted.
I understand not wanting all symlinks to be protected, but surely if the original full path of the blacklisted file i.e /var is itself a symlink, then in that situation it should honour it and not allow it to be deleted?
Changed in safe-rm: | |
status: | New → Triaged |
importance: | Undecided → Low |
Changed in safe-rm: | |
milestone: | none → 1.1.0 |
assignee: | nobody → François Marier (fmarier) |
status: | Triaged → Confirmed |
Changed in safe-rm: | |
status: | Confirmed → In Progress |
Changed in safe-rm: | |
status: | In Progress → Fix Committed |
Changed in safe-rm: | |
status: | Fix Committed → Fix Released |
The reason why I excluded symlinks from the list of protected paths is that it used to be impossible to delete symlinks like this one:
ln -s /usr/lib ~/system-lib
because safe-rm was checking the true path of the file/directory (i.e. after de-referencing the symlink) against the blacklist. I figured that symlinks are not hard to re-create anyways (you never lose the underlying file/directory if you delete one) so they were probably not worth protecting.
I can see that if we were to change that this check:
IF path is a symlink AND non-dereferenced symlink is in the blacklist
then we could bring back protection for symlinks. Can you think of any problems with that approach?