Doesn't protect symbolic links

[Alex Mason]

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?

[François Marier (fmarier)]

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?

[Alex Mason (seliquity)]

No, that approach sounds perfect

[François Marier (fmarier)]

There is a possible complication with this: the realpath function is what we use to convert something like "../../usr/lib" to "/usr/lib" and that's also the function that de-references symlinks.

If we stop using it (with symlinks) to avoid de-referencing symlinks, then only absolute symlinks will be protected, not the ones in relative paths.