From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 3 19:16:08 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE62616A403 for ; Fri, 3 Nov 2006 19:16:08 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.2.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D38643D4C for ; Fri, 3 Nov 2006 19:16:08 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp8.server.rpi.edu (8.13.1/8.13.1) with ESMTP id kA3JFsIf027053; Fri, 3 Nov 2006 14:15:56 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061103050256.GA87797@nowhere> References: <20061031161640.71807.qmail@web53907.mail.yahoo.com> <20061102104744.O52313@tribble.ilrt.bris.ac.uk> <20061103050256.GA87797@nowhere> Date: Fri, 3 Nov 2006 14:15:53 -0400 To: Craig Boston , Jan Grant From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Cc: freebsd-hackers@FreeBSD.org, Daniel Valencia Subject: Re: [patch] rm can have undesired side-effects X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 19:16:09 -0000 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@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA