Subject: Re: bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

From: Eric Blake <[email-masked]>
Date: Fri, 07 Sep 2012 10:30:20 -0600

On 09/07/2012 08:54 AM, Linda Walsh wrote:
> 
> Using "." to reference content of a dir is standard in other utils -- that
> it doesn't work in 'rm' goes counter to the idea of how rm works -- you
> have
> to remove contents before trying the current dir.  It isn't logical to
> think
> that it would try the current dir before anything else -- as it goes
> completely
> contrary to how rm has to work.

At the syscall level, unlink(".") is required to fail.  To remove a
directory, you must remove its proper name.  You can use
unlink("../child") on systems like Linux that let you remove a directory
that is used as a process' current working directory (on systems like
Windows where this action is forbidden, there's no way to remove the
current working directory).  Therefore, at the shell level, POSIX will
let you do 'rm -r ../child'.  If you think that POSIX should _also_ let
you attempt 'rm -r .', then propose that as a defect report against
POSIX, rather than griping here.

> 
> I say it's a design flaw and inconsistent with other programs.

I would say that it is not a design flaw, but that it is consistent with
the fact that the unlink(".") syscall is required to fail, and that it
is consistent with other Unix implementations.  We can agree to disagree
on that point.

-- 
Eric Blake   [email-masked]    +1-919-301-3266
Libvirt virtualization library http://libvirt.org