Re: [wishlist] rm -rf to alter directories permissions if necessary

[Bob Proulx]

Yaroslav Halchenko wrote:
> PS Please CC me -- I am not on the list

> > mkdir -p d1/d2; touch d1/d2/f1; chmod -w d1/d2; rm -rf d1
> rm: cannot remove ‘d1/d2/f1’: Permission denied
> 
> so to 'rm -rf d1' I need first to chmod +w all
> directories...

Only because they were previously protected with a chmod -w before
this.  If not then you wouldn't need to change the permission again.

It is often practiced that directory trees are changed read-only to
protect them from removal.  Changing them read-only is an explicit
action with the explicit goal of preventing them from being removed.
That is the way it works.

> although at times fs not really an issue, but I am testing git-annex
> repositories with up to a million of files.  Thus running both first
> recursive chmod and then rm -r sounds (and feels) quite wasteful.

I am aware of git-annex but not really familiar with it.  However I
don't think it is a property of git-annex to chmod -w the files.  That
is happening at another step, no?  What is actually causing your
directory tree to be read-only?  If you are trying to make something
more convenient and don't want the tree to be read-only then not
changing the permissions to be read-only is the right place to do it.

> So I wondered to suggest/ask if implementing alternation of the
> parent's directory permissions if --force would be provided be a
> sensible extension to rm?

Long standing use has been that removing write capability from
directories prevents files from being removed from the directory.
Even when using rm -rf.  Changing that would create the exact opposite
and valid bug report that 'rm -rf' removed files from write protected
directories.  Worse that would be a data loss event.  rm is not
allowed to chmod directories first.

Bob