Re: Should rm(1) -Pf change file permission?

2018-04-18 Thread Grégoire Jadi
Ingo Schwarze writes: Hello Ingo, > Hi Gregoire, > > Gregoire Jadi wrote on Tue, Apr 17, 2018 at 11:44:41AM +0200: >> Ingo Schwarze writes: > >>> Feedback is welcome both on the general idea and on the specific >>> implementation. > > The result of that

Re: Should rm(1) -Pf change file permission?

2018-04-17 Thread Ingo Schwarze
Hi Gregoire, Gregoire Jadi wrote on Tue, Apr 17, 2018 at 11:44:41AM +0200: > Ingo Schwarze writes: >> Feedback is welcome both on the general idea and on the specific >> implementation. The result of that feeback was "we don't want it, the whole idea of changing this is

Re: Should rm(1) -Pf change file permission?

2018-04-17 Thread Grégoire Jadi
Ingo Schwarze writes: Hi, > Hi, > > Gregoire Jadi wrote on Fri, Mar 30, 2018 at 06:07:42PM +0200: > >> While working on a port of keyringer, I observed the following behavior >> of rm(1) with the -P option: if the file does not have write permission, >> the file is removed

Re: Should rm(1) -Pf change file permission?

2018-03-31 Thread Ingo Schwarze
Hi, Gregoire Jadi wrote on Fri, Mar 30, 2018 at 06:07:42PM +0200: > While working on a port of keyringer, I observed the following behavior > of rm(1) with the -P option: if the file does not have write permission, > the file is removed without being overwritten. > > This is not the same

Re: Should rm(1) -Pf change file permission?

2018-03-31 Thread Craig Skinner
Hi Grégoire/all, On Fri, 30 Mar 2018 18:07:42 +0200 Grégoire Jadi wrote: > ... here is a small test to demonstrate ... Same behaviour noticed and previously bugged:- http://openbsd-archive.7691.n7.nabble.com/rm-P-doesn-t-overwrite-a-user-owned-read-only-file-td266276.html Regards, -- Craig

Should rm(1) -Pf change file permission?

2018-03-30 Thread Grégoire Jadi
Hello, While working on a port of keyringer, I observed the following behavior of rm(1) with the -P option: if the file does not have write permission, the file is removed without being overwritten. This is not the same behavior as shred(1) (from sysutils/coreutils) which do not remove the file