bug#12400: rmdir runs "amok", users "curse" GNU...(as rmdir has no option to stay on 1 file system)...

[L A Walsh]

On 2/26/2019 12:10 PM, Bob Proulx wrote:
>> rm -fr --one-filesystem foo/. or 
>> cd foo && rm -fr --one-filesystem .
> 
>   rm: refusing to remove '.' or '..' directory: skipping '.'
> 
> I agree with your complaint about "rm -rf ." not working.  That is an
> annoying nanny-state restriction.  It should fail removing '.' after
> having removed all it can remove.  And it only took 16 messages in
> order to get to this root cause!  It would have been so much easier if
> you had started there.
> 
> But this report is about rmdir so let's get back to rmdir.  Any
> reports about rm should be in a separate ticket.  Mixing multiple bugs
> in any one bug ticket is confusing and bad.
---
        I think your example is where things started.

The issue with rmdir is a follow-on problem for not having
a "-x" option (don't delete from more than 1 file system),
and I recognized that from the fact that rm -fr no longer has
the ability to stay on 1 file system.

The only way you can delete files from under "." with 'rm',
and I have been told this NUMEROUS TIMES, is to use
the shell's expansion.  While I would agree one should 
remove the shell's expansion from the effects of a tool when
writing a bug report, the oft-quoted solution to 
rm -fr . not following the original design, was to use
rm -fr *.  With rm -fr *, rm no longer can delete files just
on 1-filesystem, let alone the 1 file system that the 
top of the tree "." is on.  If all subdirs underneath
"." (arbitrary directory as used in "rm -fr ."), are on 
different file systems, as all are different mount points,
then there is no fixed limit as to how many file systems it 
will affect.

Then people will say to use the find command -- which instantly
makes 'rm' worthless for the job for which it was intended.

If people want nanny behavior, like rm -i or even rm -I, let them
alias it that way.  My main issue is one can't delete all
files under a directory with 'rm' anymore.  

I've asked for it to only refuse to do so if POSIX_CORRECTLY
is set, or to add the converse IGNORE_POSIX_DOT_RESRICTIONS
(keeping the one for '/' -- as there is no reason to ever delete
'/' -- it's inefficient -- just remake the file system).
But as 'rm' was first designed, it did a depth first removal
and didn't preprocess the path looking for reasons to stop.

And I HAVE submitted multiple attemps to get rm-fr. to work
again.  They are continuously shot down such that I often
have my own version of 'rm' that also removes empty 
directories (behaving like 'rmdir').  It can't remove
'.' because it is in the dir and doesn't know the name to
remove from the parent, so that's still not affected.

If people have issues with rm having these changes, then 
I have no problem adding 'r' as a new util that does --that
would not be bound by restrictions on 'rm', it would

1) allow "rm -fr .", deleting all but the current directory and
   issue no error message due to the "-f".
and
2) delete empty directories without '-r' -- but only if it
   knows their name -- i.e. it wouldn't delete '.'.

As it stands, the only reason this bug was filed was because
it's behavior is inconsistent with what is implemented in rm
in that it has no option to stay on 1 file system (which no
longer works in 'rm' due to previously cited reasons).

Creating such a utility would be trivial -- modify 'rm' to
allow processing the dirtree below "." and allow it to process
an empty directory.

So where would you suggest going from here to get to 'there'?

Linda