Re: rm -f and unexecutable directories

[Ed Avis]

On Sat, 8 Nov 2003, Bob Proulx wrote:

>>% mkdir -p fred/jim
>>% chmod a-x fred/jim
>>% rm -rf fred
>>rm: cannot chdir from `fred' to `jim': Permission denied
>
>But by the action of your chmod you have specifically requested that
>you do not want those files removed!

But by specifying the -f option I (thought I had) specifically
requested that they _should_ be removed after all!  Compare:

% touch foo
% chmod a-w foo  
% rm foo
rm: remove write-protected regular empty file `foo'?
[C-c]
% rm -f foo
[removes the file without question]

The -f flag or similar 'force' option is there to overrule any
permissions and _force_ the files to be removed.  Or so you'd think.

>Changing this behavior would break a lot of safety that has been
>built into scripts over the years.

The behaviour cannot be changed because it would conflict with POSIX,
according to earlier messages on this list.  So the question is then
about the usefulness of a new flag 'really force', to override
permissions and remove things for certain.

Yes - you could get the same effect by first doing 'chmod -R' and then
'rm -rf', but by the same argument the -f flag to cp is redundant
because it just emulates rm followed by cp.  I feel it makes sense to
have forcing options built into the rm and cp commands themselves; of
course you don't get that behaviour unless you explicitly ask for it.

FWIW - what prompted me to suggest this feature was not that I had
chmodded files to deliberately stop them being removed.  It was just a
slightly odd tarball (not generated on a Unix system, I expect) which
created a directory lacking execute permission.  Then I tried to use
rm to clean up, and was surprised that even with the --force option it
wasn't able to do the job.

-- 
Ed Avis <address@hidden>