Subject: Behaviour of "rm -P" when file cannot be overwritten
To: None <tech-userlevel@NetBSD.org>
From: Alan Barrett <apb@cequrux.com>
List: tech-userlevel
Date: 08/23/2006 09:20:28
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?
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.
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. 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.
I also think that the "-f" (force) flag should suppress the prompt and
just delete the file even if the overwrite failed.
--apb (Alan Barrett)