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

[anonymous]

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

(Wow, I'd forgotten all about this bug report!)

The interactions between find and symlinks have complicated implications,
that's for sure.

As <berny> said:
> Finally, also rm(1) and rmdir(1) do not have an -L option - probably
> for a good reason.

There's a physical and a logical structure of a filesystem, as exemplified in
the `pwd` command's man page:
> -L, --logical
>             use PWD from environment, even if it contains symlinks
> -P, --physical
>             avoid all symlinks

Removing (rm -rf) a physical directory tree is straightforward, and it's easy
to reason about, mainly because it's a tree and therefore easy to say what
things are in the set of things to delete.

Removing a logical directory structure (because we're following symlinks, we
can't call it a tree) is straightforward too, at least from the point of view
of the algorithm:  Recursively descend the directories, delete everything you
find.

One problem: those darn symlinks can point to places you didn't really want to
delete: if someone innocently created a symlink to `/` in one of the
subdirectories then you're well on your way to an `rm -rf /` catastrophe.

It seems like the Unix philosophy is "If a tool isn't sharp enough to cut you
badly, then it's not sharp enough to use."  To which some have responded
"Sure, but don't put the sharp edges on the handle!"  

It looks a bit like the risk of `rm -rf /` is a sharp-edges-on-the-handle
problem, as any user can create them, but it could be argued either way.  It's
already in `find` and people have probably already written code that depends
on it, so that train has left the station.

As for the original problem: when a symlinked thing is deleted, I would argue
that the user intended to delete the symlink and the thing, not just the
thing: when they specify `-delete`, they want that directory entry and all it
represents to be gone.  This then prevents the 'directory not empty' and 'not
a directory' problems seen in <raf>'s comment.  If there happen to be other
symlinks that were outside the graph of things traversed, then they shall
become broken.

One more complication:

$ date > file1
$ ln -s file1 file2
$ ln -s file2 file3
$ mkdir dir1
$ ln -s dir1 dir2
$ ln -s dir2 dir3
$ ls -l

total 4
drwxrwxr-x. 2 user user 40 Oct 24 13:40 dir1
lrwxrwxrwx. 1 user user  4 Oct 24 13:40 dir2 -> dir1
lrwxrwxrwx. 1 user user  4 Oct 24 13:40 dir3 -> dir2
-rw-rw-r--. 1 user user 29 Oct 24 13:37 file1
lrwxrwxrwx. 1 user user  5 Oct 24 13:37 file2 -> file1
lrwxrwxrwx. 1 user user  5 Oct 24 13:37 file3 -> file2

$ find -L file3 dir3 -delete
find: cannot delete ‘dir3’: Not a directory

$ ls -l
drwxrwxr-x. 2 user user 40 Oct 24 13:40 dir1
lrwxrwxrwx. 1 user user  4 Oct 24 13:40 dir2 -> dir1
lrwxrwxrwx. 1 user user  4 Oct 24 13:40 dir3 -> dir2
-rw-rw-r--. 1 user user 29 Oct 24 13:37 file1
lrwxrwxrwx. 1 user user  5 Oct 24 13:37 file2 -> file1

Currently it deletes only file3, whereas I'd argue it should delete
everything.  To do that, it would need to manually follow symlink chains and
delete the links and the final filesystem object.

Thanks


    _______________________________________________________

Reply to this item at:

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

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