bug#21084: rm appears to no longer be POSIX compliant (as of 2013 edition) re: deleting empty dirs and files under <path>/.

[Linda Walsh]

Paul Eggert wrote:
> Linda Walsh wrote:
> >     Since there is no opposition to this, I presume, all you need now
> > is a patch?
>
> My impression is that hardly anybody cares about this corner case.
>
> How about the following idea instead?  We could have --no-preserve-root 
> also skip the special treatment for '.' and '..'.  That way, we 
> shouldn't need to add an option.
---

Though I've never had a problem with doing something like
'rm -fr /', I'd prefer not to chance it -- I can't believe 
this is a corner case -- not given the putrid hate spewed
at me by some BSD supporter who pushed through the mandatory restrictions.

Instead of 'rm -fr /', I prefer dd if=/dev/sda2 of=/dev/sda ...wait, where was
my new partition?   ARG!

Another issue I haven't raised yet, because this is more important to me
is the horrible execution of --one-file-system.

Since the rm -fr --one-file-system foo/. was removed and the suggested
replacements were use '*'... gee.. so you mean under "foo/' you had
bind  mounts to your root, /usr and /home partitions? But one-file-system
didn't catch it because they all were presented to 'rm' as cmd-line
args -- and the man page legalese says "when  removing  a hierarchy 
             recursively, skip any directory that is on a file system 
             different from  that  of  the  corresponding
             command line argument.

So it limits it to deleting files for all the files you used to be safe
from deleting when dir/. was allowed.  Example on my system... snapshot dir:

Filesystem                          Size  Used Avail Use% Mounted on
/dev/Data/Home-2015.04.22-03.07.02  6.8G  5.5G  1.3G  81% 
/home/.snapdir/@GMT-2015.04.22-03.07.02
/dev/Data/Home-2015.04.30-03.07.02  1.1G  913M  186M  84% 
/home/.snapdir/@GMT-2015.04.30-03.07.02
/dev/Data/Home-2015.05.17-13.11.21  762M  647M  115M  85% 
/home/.snapdir/@GMT-2015.05.17-13.11.21
/dev/Data/Home-2015.05.18-00.40.55  1.2G  981M  193M  84% 
/home/.snapdir/@GMT-2015.05.18-00.40.55
/dev/Data/Home-2015.05.18-13.05.04  1.7G  1.4G  287M  83% 
/home/.snapdir/@GMT-2015.05.18-13.05.04
/dev/Data/Home-2015.05.19-04.08.02  1.2G  957M  189M  84% 
/home/.snapdir/@GMT-2015.05.19-04.08.02
/dev/Data/Home-2015.05.20-04.08.02  922M  774M  149M  84% 
/home/.snapdir/@GMT-2015.05.20-04.08.02
/dev/Data/Home-2015.05.21-04.08.03  802M  676M  126M  85% 
/home/.snapdir/@GMT-2015.05.21-04.08.03
/dev/Data/Home-2015.05.22-04.08.02  2.3G  1.9G  421M  82% 
/home/.snapdir/@GMT-2015.05.22-04.08.02
/dev/Data/Home-2015.05.23-04.08.02  4.5G  3.7G  874M  81% 
/home/.snapdir/@GMT-2015.05.23-04.08.02
/dev/Data/Home-2015.05.24-04.08.04  7.2G  5.8G  1.4G  81% 
/home/.snapdir/@GMT-2015.05.24-04.08.04
/dev/Data/Home-2015.05.26-03.39.31  1.3G  1.1G  218M  84% 
/home/.snapdir/@GMT-2015.05.26-03.39.31
/dev/Data/Home-2015.05.27-04.08.05  5.4G  4.4G  1.1G  82% 
/home/.snapdir/@GMT-2015.05.27-04.08.05
/dev/Data/Home-2015.06.01-14.19.28  4.1G  3.3G  779M  82% 
/home/.snapdir/@GMT-2015.06.01-14.19.28
/dev/Data/Home                      1.5T  1.1T  494G  68% /home
/dev/Data/Home-2015.06.02-12.53.34  1.5T  1.1T  502G  68% 
/home/.snapdir/@GMT-2015.06.02-12.53.34

That's the type of harm caused by removing the "cd snapshots && rm -fr 
--one-file-system ."
or "rm -fr --one-file-system snapshots/."
and telling them it's not needed in rm because the shell's '*' will expand it.  
I could
safely use the disabled features in that dir -- sometimes junk builds up where 
something got
copied into a directory that didn't have the corresponding partition mounted, 
as an example.

With "snapshots" becoming more "in vogue" -- in another decade or so, 
POSIX will require banning wildcard usage from a shell (if shell-access
hasn't been disabled before that, of course... ;^).

Besides.. with my suggested change, rm would only need 1 new switch, not '2' 
like '/' did ;-),
though I admit to wanting to add "-x" (find, rsync, maybe others having such a 
switch
as meaning stay on 1-dev (--xdev) -- and if I had my druthers, using -x would 
NOT use
the fact that cmdline args were on different filesystems as an excuse to do more
than operate on "one-file-system"... (would it be that hard to check the device 
id's of
the cmd-line args before starting a recursive delete based off them?)...

Eh...like I said, for me, just the special option to allow "." or dir/. is far 
more
important.