On 22 Aug 2006, at 07:33, Bernd Ernesti wrote:

> Hi,
>
> 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
>>
>> Idea from FreeBSD, fix is slighty diff however...
>
> It would be nicer if you would mention the problem in this mail and
> attached the patch to your mail.
>
> To quote the patch:
>
> : Only unlink the file if indeed it has been overwritten. For example,
> :
> : $echo "hello" > moo; chmod 444 moo
> : $rm -P moo
> : override r--r--r--  liamfoy/users for 'moo'? y
> : rm: moo: Permission denied
> : $
> :
> : File moo will have been removed without have being written over.
> :
> : Also, when we goto err remember to close fd.
>
> That was the example before your patch, how would the example
> look like after someone applied it?
>
> I'm currious about the behaviour if you said yes to overwrite it
> and then 'rm' would try to remove it after that. Would it ask again
> to remove it because of the missing write permission and what
> would happen if you denie that then?
> Or would the -P unconditionally overwrite the file without
> asking for the permission and then the override message comes
> from the remove stage?
>
> Bernd
>

I have also added another check from FreeBSD in check() for a more
graceful return (instead of Permission Denied).

The patch will basically make sure that the requested file is  
overwritten
before it will remove it, since you obviously want to overwrite it  
first.

If it can't overwrite it won't remove it. If it can overwrite it will  
remove it.

The question is whether -f should cause the removal regardless of the
overwrite result (I personally think yes).

That make more sense?

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