Subject: Re: Behaviour of "rm -P" when file cannot be overwritten
To: Alan Barrett <apb@cequrux.com>
From: Liam J. Foy <liamfoy@sepulcrum.org>
List: tech-userlevel
Date: 08/23/2006 14:24:53
On 23 Aug 2006, at 08:20, Alan Barrett wrote:

> On Mon, Aug 21, 2006 at 10:47:54PM +0100, Liam J. Foy wrote:
>> Since this is rm, anyone any objections to the following patch:
>>
>> http://netbsd.org/~liamjfoy/rm.c.patch
>
> It would have been nice if you had explained what this was about, so
> that we didn't have to reverse engineer the problem description  
> from the
> patch.
>
> OK, so "rm -P filename" tries to overwrite the file before deleting
> it, and the question is: What should happen if the file cannot be
> overwritten?

Correct. The current code tries to overwrite the file and will then
try remove the file, regardless of whether the overwrite succeeded.

>
> At present, if the file cannot be overwritten, then the file is just
> deleted witout being overwritten.  I think that this behaviour is  
> wrong;
> I'd expect the command to report a fialure if it can't do what was
> requested.

Agreed - which is what the patch does.

>
> With your patch, if the file cannot be overwritten, there's some
> sort of "are you sure" prompt, but I find the wording of the message
> confusing.  It's not clear from the message that, if you answer "yes",
> the file will be deleted without being overwritten.

What prompt is this exactly? Can I see an example? The current
patch just displays a failure message and moves on leaving
the file intact.

For example:

carpy: {12} touch moo ; chmod 444 moo
carpy: {13} ls
moo
carpy: {14} rm -P moo
rm: moo: -P was specified, but file is not writable
carpy: {15} ls
moo
carpy: {16}

We could of course display a failure message and allow the user
to remove the file even if it hasn't been overwritten. (like I think
you mentioned below). I think just displaying a failure message
is enough, though.


> At the very least,
> I suggest changin "-P was specified, but file is not writable" to "-P
> was specified but file could not be overwritten"; otherwise people
> might think "no problem, rm probably just chmod()ed the file before
> overwriting it as I requested".  I'd prefer an even more explicit
> "Delete without overwriting?" message.

That seems a sensible language change. I'm not sure they would
think that, but OK :-).

>
> I also think that the "-f" (force) flag should suppress the prompt and
> just delete the file even if the overwrite failed.

Agreed.

>
> --apb (Alan Barrett)

		---
		Liam J. Foy
		<liamjfoy@netbsd.org>