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 feeback was "we don't want it, the whole
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 pointless and dangerous"
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 without being overwrit
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 behavio
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 Skin
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 i
