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!
>
>Not quite.  You just pre-answered the questions to be asked as yes.

Yup.  I expected that -f would 'force' removal, but in fact it
doesn't.

>Here is what the info page says.
>
>`-f'
>`--force'
>     Ignore nonexistent files and never prompt the user.  Ignore any
>     previous `--interactive' (`-i') option.

I know that rm's behaviour is consistent with the info page and with
POSIX.  So I am not reporting a bug.  Instead I make two
observations: that the --force flag is perhaps misnamed, and that an
additional option to _really_ force things might be useful.

>Also, there really are multiple operations happening with the
>directory find'ing, chmod'ing and rm'ing.  These are not atomic
>operations.

True, but then neither is the normal action of rm -r.  It's possible
to have a race condition where you're removing files from a directory
at the same time someone else is creating them, and so the rm -r
fails.

>Here is what I was originally thinking about.  This one has been
>debated previously and can't be changed.
>
>  mkdir -p one/two/three
>  chmod -R a-w one
>  rm -rf one
>  rm: cannot remove directory `one/two/three': Permission denied
>  rm: cannot remove directory `one/two': Permission denied
>  rm: cannot remove directory `one': Directory not empty

Hmm.  Again this would be a candidate for a --really-force flag, if
one were added.  I know that the behaviour of -f cannot be changed.

>Of course all of the directories are removed in this case in spite of
>the inability to search the directory.  That is, the following works.
>
>  mkdir one
>  chmod a-x one
>  rmdir one
>
>So perhaps there is some room for change there.  Perhaps rm should
>attempt rmdir on the directory even though it can't look into it.

Hmm maybe, but not as a change to rm's current behaviour since as you
say that would break what people (and POSIX) expect.  It would have to
be part of some new option.  But if you were going to add such an
option, merely trying an rmdir() seems too weak to be worth bothering.

>>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.
>
>Actually, no, not for the non-writable file case.  It just turns off
>the question.

According to cp(1):

       -f, --force
              if an existing destination file cannot  be  opened,
              remove it and try again

This is analogous to what I had in mind for rm: try some additional
operation (unlink, chmod, whatever) which will let the command
succeed.

In the case of cp, the -f flag does *not* simply stop a question being
asked.  It seems to do that, but also more importantly do an
additional step (unlink) if necessary.  For example:

% touch fred jim
% chmod a-w jim
% cp fred jim
cp: overwrite `jim', overriding mode 0444? y
cp: cannot create regular file `jim': Permission denied
% cp -f fred jim
[succeeds]

So the -f flag to cp is clearly not just a means to answer 'yes' to
some question.  For rm, as you say, it's different and -f is just
equivalent to lots of 'y' (plus ignoring files that don't exist).  But
the example of cp shows that adding a flag to 'do some extra stuff to
force the operation to happen' is not such a strange idea.

>The -f option does not perform any 'chmod' operations.  It just
>suppresses the artificially created message.  I say artificially
>created because the rm command as part of trying to be helpful goes
>out of its way to ask the user if they really want to remove the
>file solely based upon the clue that it is not writable.  I have
>always thought that behavior gratuitous.  It is trying to create a
>different model of the filesystem than the one that actually exists.

Agreed.  But it's too late to change now.

>>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.
>
>At least that is not something that happens every day!  :-)

Nonetheless there should be some program which is able to delete files
even in cases like the above, and if not rm then what?

-- 
Ed Avis <address@hidden>