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
