Mac OS X uses the FreeBSD's behaviour.
I don't see any problem with the current implementation
of "rm -P". I think I agree with Mike Meyers (omg!)
My 0.01 cents
--
JFRH
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis
First of all, just for the record, I also vote for removing
-P from rm(1), for reasons already mentioned by others.
It was intended as a security feature, but such a security
feature must have a well defined and very clear behaviour,
and it must work correctly under all circumstances. The -P
opti
@freebsd.org
Sent: Saturday, November 4, 2006 10:22:36 PM
Subject: Re: [patch] rm can have undesired side-effects
On Sun, 5 Nov 2006 08:09:23 +0200
Kostik Belousov <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 05, 2006 at 05:28:32AM +0100, Joerg Pernfuss wrote:
> > And I still have no idea
On Sun, 5 Nov 2006 08:09:23 +0200
Kostik Belousov <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 05, 2006 at 05:28:32AM +0100, Joerg Pernfuss wrote:
> > And I still have no idea why ln(1) allows links to files the user
> > has no access rights whatsoever, in a directory the owner of the
> > file has no
On Sun, Nov 05, 2006 at 05:28:32AM +0100, Joerg Pernfuss wrote:
> And I still have no idea why ln(1) allows links to files the user has
> no access rights whatsoever, in a directory the owner of the file
> has no access to in the first place. And what happens when I link the
> 0600 file state_secre
On Sat, 4 Nov 2006 18:22:39 -0800 (PST)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> :I agree. I will make this change in DragonFly right now, in
> : fact. The -P option really needs to be consistent across
> : environments and my take on the original design was so users could
> : alias rm to
:...
:BSD behaviour:
:- OpenBSD handles hardlinks since 3.3:
: -P Overwrite regular files before deleting them. Files
:are overwritten three times, first with the byte pattern
:0xff, then 0x00, and then 0xff again, before they are
:deleted. Files with
::...
::Although I am a big defender of "the user should know what he does",
::the "right thing to do"[TM] would probably be to sync the behaviour
::of FreeBSD's rm(1) to OpenBSD and lobby NetBSD and DragonFlyBSD to do
::the same :)
::
:: Joerg
:
:I agree. I will make this change in Drago
At 11:02 PM -0600 11/2/06, Craig Boston wrote:
On Thu, Nov 02, 2006 at 10:52:19AM +, Jan Grant wrote:
> This is, I reckon, the only sensible suggestion thus far: if the
> FS doesn't help you then you are implicitly depending on the FS
> implementation to ensure you are writing over the ori
On Thu, Nov 02, 2006 at 10:52:19AM +, Jan Grant wrote:
> This is, I reckon, the only sensible suggestion thus far: if the FS
> doesn't help you then you are implicitly depending on the FS
> implementation to ensure you are writing over the original data blocks
> anyway.
And you may very wel
On Tue, 31 Oct 2006, Daniel Valencia wrote:
> if the file is not writable, return with error.
> if the file has multiple links, and option -f was not specified,
> return with error.
> overwrite the file.
> optionally, unlink the file.
>
> Additionally, -P should either be rm'ed from rm, or added
> Having cleared my head a bit more, I realise most of
> this can be done with consecutive runs of 'dd'.
> I think I've reached a conclusion here.
that is, install "ports/sysutils/obliterate/"?
> Tim.
[SorAlx] ridin' VN1500-B2
___
freebsd-hackers@fre
--- Bakul Shah <[EMAIL PROTECTED]> wrote:
> > Having thought this over some more, if a
> > shred/scramble/scrub command is created in its own
> > right, then a number of new features could be
> added
> > that do not currently exist.
>
> > - The command could be writen to protect a single
> > fi
> Having thought this over some more, if a
> shred/scramble/scrub command is created in its own
> right, then a number of new features could be added
> that do not currently exist.
> - The command could be writen to protect a single
> file, or, it could also write to an entire file
> system/media.
Doug Barton
> <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> freebsd-hackers@freebsd.org
> Sent: Monday, October 30, 2006 12:20:33 PM
> Subject: Re: [patch] rm can have undesired
> side-effects
>
>
> --- Bakul Shah <[EMAIL PROTECTED]> wrote:
&g
iginal Message
From: Tim Clewlow <[EMAIL PROTECTED]>
To: Bakul Shah <[EMAIL PROTECTED]>; Doug Barton <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; freebsd-hackers@freebsd.org
Sent: Monday, October 30, 2006 12:20:33 PM
Subject: Re: [patch] rm can have undesired side-ef
> IMHO many problems arise when someone tries to please even the
> stupidest user by writing a fool-proof software. To me the beauty
> of Unixes is that they are _not_ fool-proof, e.g. your are holding
> a real gun, you should be carefull not to point it to your head
> and pull the trigger.
If we
On Mon, Oct 30, 2006 at 01:05:06PM -0800, Doug Barton wrote:
> Simon L. Nielsen wrote:
>
> > Personally I think rm should do what you ask it to do - if you ask it
> > to overwrite a file which has multiple links, well... though luck.
>
> Sorry, I disagree. It's not always obvious to the user wh
In <[EMAIL PROTECTED]>, Freddie Cash <[EMAIL PROTECTED]> typed:
> On Monday 30 October 2006 01:17 pm, Mike Meyer wrote:
> > In <[EMAIL PROTECTED]>, Doug Barton <[EMAIL PROTECTED]>
> typed:
> > > Simon L. Nielsen wrote:
> > > > Personally I think rm should do what you ask it to do - if you ask
> >
Mike Meyer wrote:
> In <[EMAIL PROTECTED]>, Doug Barton <[EMAIL PROTECTED]> typed:
>> Simon L. Nielsen wrote:
>>> Personally I think rm should do what you ask it to do - if you ask it
>>> to overwrite a file which has multiple links, well... though luck.
>> It's all well and good to say, "tough l
On Monday 30 October 2006 01:17 pm, Mike Meyer wrote:
> In <[EMAIL PROTECTED]>, Doug Barton <[EMAIL PROTECTED]>
typed:
> > Simon L. Nielsen wrote:
> > > Personally I think rm should do what you ask it to do - if you ask
> > > it to overwrite a file which has multiple links, well... though
> > > lu
In <[EMAIL PROTECTED]>, Doug Barton <[EMAIL PROTECTED]> typed:
> Simon L. Nielsen wrote:
> > Personally I think rm should do what you ask it to do - if you ask it
> > to overwrite a file which has multiple links, well... though luck.
> It's all well and good to say, "tough luck," but I don't thin
Simon L. Nielsen wrote:
> Personally I think rm should do what you ask it to do - if you ask it
> to overwrite a file which has multiple links, well... though luck.
Sorry, I disagree. It's not always obvious to the user when a file has
hard links, and I can't see any situation where the pre-rec
--- Bakul Shah <[EMAIL PROTECTED]> wrote:
> Sorry if I tuned in late:-)
>
> I vote for taking *out* -P. It is an ill-designed
> feature.
> Or if you keep it, also add it to mv, cp -f & ln -f
> since
> these commands can also unlink a file and once
> unlinked in
> this matter you can't scrub it
On 2006.10.30 21:31:51 +1100, Peter Jeremy wrote:
> On Mon, 2006-Oct-30 19:38:49 +1100, Peter Jeremy wrote:
> >the user is unaware that there are multiple links. I don't think
> >that just unlinking the file and issuing a warning is a good solution
> >because it's then virtually impossible to loca
Doug Barton writes:
> Bakul Shah wrote:
> > Sorry if I tuned in late:-)
> >
> > I vote for taking *out* -P. It is an ill-designed feature.
> > Or if you keep it, also add it to mv, cp -f & ln -f since
> > these commands can also unlink a file and once unlinked in
> > this matter you can't scrub i
Bakul Shah wrote:
> Sorry if I tuned in late:-)
>
> I vote for taking *out* -P. It is an ill-designed feature.
> Or if you keep it, also add it to mv, cp -f & ln -f since
> these commands can also unlink a file and once unlinked in
> this matter you can't scrub it. And also fix up the behavior
>
Sorry if I tuned in late:-)
I vote for taking *out* -P. It is an ill-designed feature.
Or if you keep it, also add it to mv, cp -f & ln -f since
these commands can also unlink a file and once unlinked in
this matter you can't scrub it. And also fix up the behavior
for -P when multiple links. An
Peter Jeremy wrote:
> On Sun, 2006-Oct-29 18:11:54 -0800, [EMAIL PROTECTED] wrote:
>> I think a very strong case can be made that the *intent* of -P --
>> to prevent retrieval of the contents by reading the filesystem's
>> free space -- implies that it should affect only the "real" removal
>> of th
On Mon, 2006-Oct-30 17:39:54 +0800, LI Xin wrote:
>Well thought, I think that you are correct that specifying -P should do
>nothing but generate a warning.
>
>In addition to this I have changed the behavior a bit (patch attached)
>that, if -f is specified along with -P, the overwritten is happen an
Peter Jeremy wrote:
> On Mon, 2006-Oct-30 19:38:49 +1100, Peter Jeremy wrote:
>> the user is unaware that there are multiple links. I don't think
>> that just unlinking the file and issuing a warning is a good solution
>> because it's then virtually impossible to locate the other copy(s)
>> of the
On Mon, 2006-Oct-30 19:38:49 +1100, Peter Jeremy wrote:
>the user is unaware that there are multiple links. I don't think
>that just unlinking the file and issuing a warning is a good solution
>because it's then virtually impossible to locate the other copy(s)
>of the file, which remains viewable.
Joerg Pernfuss wrote:
> On Mon, 30 Oct 2006 19:38:49 +1100
> Peter Jeremy <[EMAIL PROTECTED]> wrote:
>
>> I agree. Doing "rm -P" on a file with multiple links suggests that
>> the user is unaware that there are multiple links. I don't think
>> that just unlinking the file and issuing a warning i
> > protections at a later date. Unless Alice notices that her file
> > has a second link before she deletes it, when she issues "rm -P",
> > she will lose her link to the file (and her only way of uniquely
> > identifying it) whilst leaving the remaining link to the file in
> > Mallory's control
Peter Jeremy wrote:
> On Mon, 2006-Oct-30 03:32:09 +, Xin LI wrote:
>> Be more reasonable when overwrite mode is specified while there
>> is hard links. Overwritting when links > 1 would cause data
>> loss, which is usually undesired.
>
> Another way of looking at it is that not overwritin
On Mon, 30 Oct 2006 19:38:49 +1100
Peter Jeremy <[EMAIL PROTECTED]> wrote:
> I agree. Doing "rm -P" on a file with multiple links suggests that
> the user is unaware that there are multiple links. I don't think
> that just unlinking the file and issuing a warning is a good solution
> because it'
On Sun, 2006-Oct-29 18:11:54 -0800, [EMAIL PROTECTED] wrote:
>I think a very strong case can be made that the *intent* of -P --
>to prevent retrieval of the contents by reading the filesystem's
>free space -- implies that it should affect only the "real" removal
>of the file, when its blocks are re
Joerg Pernfuss wrote:
> On Mon, 30 Oct 2006 02:43:58 +0100
> Joerg Pernfuss <[EMAIL PROTECTED]> wrote:
>
>> That would mean that `rm -P ' with having a link count of
>> at least 2, would behave like `rm ' (and like Romain suggested).
>
>
> Correction after some `read the frakkin code':
>
> if
- Original Message -
From: "Mike Meyer" <[EMAIL PROTECTED]>
Actually, rm -f either removes no copies or removes them all, because
there's only one copy. It either gets removed (if this was the last
link) or it doesn't. And you seem to have missed my point. Having a
"destroy this data" opt
In <[EMAIL PROTECTED]>, Steven Hartland <[EMAIL PROTECTED]> typed:
> Mike Meyer wrote:
> >> That maybe the case but does rm -f remove all copies?
> >> Nope so its behaviour is safe even with multiple hardlinks.
> > Of course it doesn't remove all copies - because there *aren't*
> > multiple copies
- Original Message -
From: "Joerg Pernfuss" <[EMAIL PROTECTED]>
Err, that is OpenBSD code :)
Time for a minor code and doc update?
Ah sorry though you meant that was FreeBSD code and it
was just the docs out of alignment.
Yes I agree this should be the behaviour of -P.
Steve
On Mon, 30 Oct 2006 02:24:46 -
"Steven Hartland" <[EMAIL PROTECTED]> wrote:
> From: "Joerg Pernfuss" <[EMAIL PROTECTED]>
> > Correction after some `read the frakkin code':
> >
> > if (sbp->st_nlink > 1) {
> > warnx("%s (inode %u): not overwritten due to multiple links",
> > file, sbp->s
From: "Joerg Pernfuss" <[EMAIL PROTECTED]>
Correction after some `read the frakkin code':
if (sbp->st_nlink > 1) {
warnx("%s (inode %u): not overwritten due to multiple links",
file, sbp->st_ino);
return (0);
The link is removed, the file is not overwritten and a
warning is generated.
Mike Meyer wrote:
That maybe the case but does rm -f remove all copies?
Nope so its behaviour is safe even with multiple hardlinks.
Of course it doesn't remove all copies - because there *aren't*
multiple copies. There is only *one* copy, with multiple hardlinks.
You told it to remove one hard
On Mon, 30 Oct 2006 12:30:02 +1030
"Daniel O'Connor" <[EMAIL PROTECTED]> wrote:
> > Silently ignoring user specified options is seldom a good way to go.
> > The user explicitly stated he wants to wipe the file contents.
>
> I disagree that the user really meant to wipe the file if its link
> coun
> ... deleted files are lost.
Not if another hard link exists!
I think a very strong case can be made that the *intent* of -P --
to prevent retrieval of the contents by reading the filesystem's
free space -- implies that it should affect only the "real" removal
of the file, when its blocks are re
On Mon, 30 Oct 2006 02:43:58 +0100
Joerg Pernfuss <[EMAIL PROTECTED]> wrote:
> That would mean that `rm -P ' with having a link count of
> at least 2, would behave like `rm ' (and like Romain suggested).
Correction after some `read the frakkin code':
if (sbp->st_nlink > 1) {
wa
On Monday 30 October 2006 10:06, Joerg Pernfuss wrote:
> > I guess that it can be fixed (in case it is not desired) by:
> > - Ignoring the -P option when the link count is greater then one, or
>
> Silently ignoring user specified options is seldom a good way to go.
> The user explicitly stated he
On Sun, 29 Oct 2006 23:57:45 -
"Steven Hartland" <[EMAIL PROTECTED]> wrote:
> That maybe the case but does rm -f remove all copies?
> Nope so its behaviour is safe even with multiple hardlinks.
>
> From the description I've seen thats not the case for -P
> here and as such I dont think its q
In <[EMAIL PROTECTED]>, Steven Hartland <[EMAIL PROTECTED]> typed:
>
> - Original Message -
> From: "Joerg Pernfuss" <[EMAIL PROTECTED]>
> >> I guess that it can be fixed (in case it is not desired) by:
> >> - Ignoring the -P option when the link count is greater then one, or
> > Silent
That maybe the case but does rm -f remove all copies?
Nope so its behaviour is safe even with multiple hardlinks.
No. rm unlinks a file from a directory. If the file had no more
links, it is deleted as well.
There's no surprise at all on the behavior of rm with hard links.
Borja.
- Original Message -
From: "Joerg Pernfuss" <[EMAIL PROTECTED]>
I guess that it can be fixed (in case it is not desired) by:
- Ignoring the -P option when the link count is greater then one, or
Silently ignoring user specified options is seldom a good way to go.
The user explicitly s
On Sun, 29 Oct 2006 23:28:47 +0100
Romain Tartiere <[EMAIL PROTECTED]> wrote:
> The rm utility provides a "-P" option for overwriting files before
> removing them. I was wondering about the behaviour of it on regular
> files with more than one hard link.
> I just wrote a few lines in a file, creat
53 matches
Mail list logo
