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
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
, 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 why ln(1) allows links to files the user
::...
::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
:...
: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
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 rm -P
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
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 access
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
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 as a
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 well
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
]
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-effects
--- Bakul Shah [EMAIL PROTECTED] wrote:
Sorry if I tuned in late
- Original 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
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.
--- 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
file, or, it
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
___
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
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's then
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 overwriting when
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.
well,
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 is a good
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.
I
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 file,
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 the file,
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.
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
for -P
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 it. And also
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 locate the
--- 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. And also
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
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 and
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 think that's
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
luck.
It's
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 luck, but I
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
it to overwrite a
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 when a
Hello
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, created an hard link to it and rm
-P the first one. The content of the second one was
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, created an
- 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
That maybe the case but does rm -f file 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.
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
Silently ignoring user
On Sun, 29 Oct 2006 23:57:45 -
Steven Hartland [EMAIL PROTECTED] wrote:
That maybe the case but does rm -f file 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 quite
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 wants
On Mon, 30 Oct 2006 02:43:58 +0100
Joerg Pernfuss [EMAIL PROTECTED] wrote:
That would mean that `rm -P file' with file having a link count of
at least 2, would behave like `rm file' (and like Romain suggested).
Correction after some `read the frakkin code':
if (sbp-st_nlink 1) {
... 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
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
count is 1.
Mike Meyer wrote:
That maybe the case but does rm -f file 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
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.
Hehe so
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-st_ino);
return (0);
In [EMAIL PROTECTED], Steven Hartland [EMAIL PROTECTED] typed:
Mike Meyer wrote:
That maybe the case but does rm -f file 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
- 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
- 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 option
Joerg Pernfuss wrote:
On Mon, 30 Oct 2006 02:43:58 +0100
Joerg Pernfuss [EMAIL PROTECTED] wrote:
That would mean that `rm -P file' with file having a link count of
at least 2, would behave like `rm file' (and like Romain suggested).
Correction after some `read the frakkin code':
if
54 matches
Mail list logo
