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.
