[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [coreutils] A more forgiving rm.

From: Jason
Subject: Re: [coreutils] A more forgiving rm.
Date: Tue, 10 Aug 2010 18:53:56 -0700

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.


On Mon, Aug 9, 2010 at 11:35 AM, Dan Hipschman <address@hidden> wrote:
On Mon, Aug 09, 2010 at 02:04:38PM +0100, P?draig Brady wrote:
> I'm not sure an option like this would help much.
> It might give a false sense of security more than anything.

On the contrary, I have been in precisely the situation where it would
help, which is why I wrote this patch. ;-)

I'm not sure what false sense of security this would give.  The option
clearly does not prevent removal of files system-wide.  It prevents
removal of those files in the blacklist during a particular invocation
of `rm'.  What's confusing about that?  It's not a replacement for
backups; it's purely there, in my mind, as a convenient safeguard
against accidental removal of files.  After all, do you really want to
hunt down that file and restore it?  An option that saves you anywhere
from 10 minutes to hours figuring out what you deleted and restoring
it seems like a big win.

> Between rm -I, immutable flags, ACLS and backups
> one is suitably covered.

These all have problems that I explained in the original email and

I'd like to mention with respect to the usefulness of the patch that
the perl wrapper, safe-rm, seems popular enough to prove its
usefulness.  It's been in Ubuntu's universe repository as far back as
Intrepid.  Integrating the functionality with coreutils allows us to
improve on it in a number of ways.

Thanks for your consideration,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]