[bug #46305] Doing "find -L . -type d -delete" fails on symlinks to directories.

[raf]

Follow-up Comment #7, bug #46305 (project findutils):

[comment #6 comment #6:]
> It looks like the right thing to do is to delete the link and the thing the
link points to, if the `-L` option (follow links) is enabled.

As I tried to explain earlier, I think that interpretation is incorrect and
unhelpful. That interpretation leads to the problem being seen as very
complicated and difficult and dangerous, and so very unlikely to ever be
fixed.

My interpretation of the problem is simple, and lends itself to a trivial
solution that would improve the user experience immediately (by replacing a
failure to act and the accompanying error message with some useful, safe, and
consistent behaviour).

I think it's perfectly reasonable to accept (and document the fact) that
symlink-following (-L) applies to the search/traversal through the directory
structure, but it does not apply to actual deletion of symlinks that were
matched via searching.

When I have wanted to delete with -L, I certainly didn't want
symlink-following to apply to the deletion. If it did, I'd want another option
to disable it, although I'd want it disabled by default. Symlink-following
deletion (if it exists at all) should be a new, separate command line option
so as not to confuse that functionality with the functionality of -L. And I
think it unlikely that most people would want symlink-following to apply to
deletion if they thought sufficiently about the consequences of such
behaviour.

I suggest accepting the patch I submitted that fixes this problem the simple
way. And then, if enough users actually complain that the deletion should have
been more aggressive by following the symlinks being deleted, that it could be
explained to them that they really don't want that behaviour. Without knowing
what other symlinks might point to the deleted symlink target, such an
operation could often be a disaster. If they really do want that behaviour, a
nested find/exec/find command would probably meet their needs.

Please remember that this bug report isn't about deletion not following
symlinks. It's just about the failure and error message when find(1) tries to
rmdir(2) a symlink whose target is a directory. When the symlink's target is a
non-directory, the operation is unlink(2) instead and it works. It works by
unlinking the symlink, not the target. The ability to unlink a symlink whose
target is a directory would be consistent and useful behaviour. No user has
complained that deleting a symlink to a file should also delete the target
file, or that deleting a symlink to a directory should delete the target
directory. That idea came up in the discussion of this bug report, but it is
not what this bug report is about.

The patch could even be seen as a temporary stage that at least fixes the
error, and adds the deletion of the symlink, and resolves this bug. The
question of whether or not any user actually wants more aggressive
symlink-following deletion can be left to a subsequent feature request or bug
report about that actual issue. And if that feature request were ever
implemented, it would still be backwards-compatible. So I don't see any
compelling reason not to apply the patch and resolve this bug.

Just in case the unhelpful interpretation continues to prevail, and this bug
is never fixed in find(1), and anyone else comes here hoping for the solution,
they can use my "rawhide" file-finding program instead
(https://raf.org/rawhide) which behaves in the way I have suggested.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?46305>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/