coreutils
[Top][All Lists]
Advanced

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

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


From: Bob Proulx
Subject: Re: [wishlist] rm -rf to alter directories permissions if necessary
Date: Sat, 31 Jan 2015 21:28:39 -0700
User-agent: Mutt/1.5.23 (2014-03-12)

Yaroslav Halchenko wrote:
> It is a feature of git-annex:  it explicitly chmods directories
> containing the load to avoids files accidental removal.  So they are
> chmod'ed intentionally for good.   It is just that I am experimenting so
> requiring creating/removal of those annex'ed repositories, and inability
> to remove those repositories in a single traversal is somewhat annoying
> when it takes notable time to even simply traverse that file hierarchy.

Then this isn't something that is a routine usage.  Rather an unusual case.

> And then it is not that all directories/files are chmod -w -- so by
> 'chmod -R +w .git/annex/objects' I am actually causing chmod considering
> files which I do not care to +w for.

Oh, you are deleting the git repository side of things.  Is there a
git-annex command to do that?  Maybe that is the right thing.

In any case don't do 'chmod -R +w .git/annex/objects' as that isn't
what you want.  You don't care about the files.  You only care about
making the directories writable.

  find .git -type d -exec chmod u+w {} +

Try that command.  That should be much faster as it only changes
directories.

I would probably stop there without thinking further.  All of your
.git files will be the same.  But in the general case with some one
way and only a few the other with a little more typing can probably
tune up the speed a little by only looking at dirs that need it.

  find $dir -type d ! -perm -u+w -exec chmod u+w {} +

> > 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.
> 
> not a choice for me here ;)

Note that you haven't actually said why not yet.

> > 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.
> 
> yeah -- I hear you, rm -rf behavior shouldn't change for sure,  but e.g.
> rm -rF could really force things ;)

I am of the opinion that adds code bloat that it shouldn't add.  It
doesn't really do anything that isn't already handled in other ways.
That old thread that Pádraig linked to refreshed my memory about why I
didn't like it.  :-)

Bob



reply via email to

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