[patch] rm can have undesired side-effects

[Garance A Drosehn]

At 11:02 PM -0600 11/2/06, Craig Boston wrote:
>On Thu, Nov 02, 2006 at 10:52:19AM +0000, 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 not be.  If the underlying FS is say for example
>journaled or snapshotted, your new data blocks may go to a completely
>different part of the disk.  For UFS today -P may work most of the time,
>assuming no snapshots or other events moving the file.  With gjournal
>and gvirtstor coming who knows if that will remain true.
>
>That doesn't even take into account things like unionfs or other VFS
>stacking.
>
>If writing zeros or whatever to a file (that may or may not overwrite
>the previous contents on disk) is really what you want to do, dd works
>just fine for the task.
>
>/me votes for removing the -P misfeature altogether

I'm inclined to agree that the option should be removed.  We can't seem
to agree on how it should work with links.  We can't guarantee that it
will work even if we agreed on when it should work.  And putting the
feature in 'rm' does no good at all when it is some other command
(such as 'mv') which is going to unlink() the filename.

I think this is a case where we should have stuck with the idea that
separate features should be implemented in separate commands.  'rm'
is just not a good command to write a lot of data into a file.  In
this case, we're not even interested in writing "to the file", but
what we really want is to write to specific sectors of a disk.

-- 
Garance Alistair Drosehn     =               drosehn at rpi.edu
Senior Systems Programmer               or   gad at FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA