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/