bug-coreutils
[Top][All Lists]
Advanced

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

bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it


From: Alan Curry
Subject: bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it
Date: Fri, 7 Sep 2012 23:57:12 -0500 (GMT+5)

Linda Walsh writes:
> 
> Alan Curry wrote:
> > Linda Walsh writes:
> >> So far no one has addressed when the change in "-f' went in
> >> NOT to ignore the non-deletable dir "." and continue recursive delete,
> > 
> > In the historic sources I pointed out earlier (4.3BSD and 4.3BSD-Reno) the 
> > -f
> > option is not consulted before rejecting removal of "." so I don't think the
> > change you're referring to is a change at all. -f never had the effect you
> > think it should have.
> > 
> If I was using BSD, I would agree.
> ---
> But most of my usage has been on SysV compats Solaris, SGI, Linux, a short
> while on SunOS back in the late 80's, but that would have been before it
> changed anyway.

SGI is dead, Sun is dead, the game's over, we're the winners, and our rm has
been this way forever.

> 
> For all i know it could have been a vendor addin, but that's
> not the whole point here.
> 
> Do you want to support making "." illegal for all
> gnu utils for addressing content?

I don't think "addressing content" is a clearly defined operation, no matter
how many times you repeat it.

Consistency between tools is a good thing, but consistency between OSes is
also good, and we'd be losing that if any change was made to GNU rm's default
behavior. Even OpenSolaris has the restriction: see lines 160-170 of
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/rm/rm.c

> 
> I think you'll find many more people against the idea and wondering
> why it's in 'rm' and why "-f" doesn't really mean ignore all the errors
> it can and why that one should be specially treated.  Of course they also 
> might
> wonder why rm doesn't follow the necessary algorithm for deleting files --
> and delete contents before dying issuing an error for being unable to delete
> a parent.  Which might also raise why -f shouldn't be usable to silence 
> permission
> or access errors as it was designed to.

Look, I agree isn't not logical or elegant. But we have a standard that all
current Unices are obeying, and logic and elegance alone aren't enough to
justify changing that.

A new option that you can put in an alias is really the most realistic goal.

-- 
Alan Curry





reply via email to

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