Re: [coreutils] A more forgiving rm.

[Dan Hipschman]

On Tue, Aug 10, 2010 at 06:53:56PM -0700, Jason wrote:
> I just rsync everything once an hour to another machine with a bigger hard
> drive, and then do an rsync --delete when the drive gets full. Version
> control can be helpful too. What happens if you blacklist a file thru a
> symlink, or rm a file thru a symlink? I didn't see anything to deal with
> that. The chances of having added the file that you didn't want to delete to
> this list is quite small.

Thanks for the feedback.

Not everybody has another machine to which to rsync, so many users
don't have up-to-the-hour backups.  Again, this isn't a replacement
for backups, it's intended to be a way to catch stupid mistakes, such
as tar does by failing if the user forgot to specify the file list
(which is really a catch for users who forgot the archive file name).

In the case of removing a symlink to a file it doesn't matter because
the original file is the one that counts.  If you blacklist a symlink
instead of the original, or recursively remove a directory's contents
through a symlink to the directory, then in its current state this
won't help.  Obviously the code could (and probably should) be amended
to handle that.

I realize that coreutils favors size, speed and correctness over user
friendliness, but I think the change has merit in that 1) it's enabled
explicitly, so it won't bother anyone who doesn't want it; 2) it's a
small change, so it's not bloating the code much; and 3) it could save
users from headaches.  In other words, we're not really trading
anything away except a small size increase.

On my system the executable size increased from 50K to 58K (stripped).
I bet a good chunk of that came from the inclusion of the hash module.
In order to check for symlinks, I don't think we could even use a hash
table, so the final code size would likely be smaller.