From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 30 02:14:49 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 3039C16A40F for ; Mon, 30 Oct 2006 02:14:49 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CC0843D55 for ; Mon, 30 Oct 2006 02:14:48 +0000 (GMT) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id k9U2ChDL098215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 29 Oct 2006 18:12:44 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id k9U2ChaR098214; Sun, 29 Oct 2006 18:12:43 -0800 (PST) Received: from fbsd61 ([192.168.200.61]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA02520; Sun, 29 Oct 06 18:11:16 PST Date: Sun, 29 Oct 2006 18:11:54 -0800 From: perryh@pluto.rain.com To: elessar@bsdforen.de Message-Id: <45455f6a.yNcc0kkyEKpoRv3m%perryh@pluto.rain.com> References: <20061029222847.GA68272@marvin.astase.com> <20061030003628.42bc5f8d@loki.starkstrom.lan> In-Reply-To: <20061030003628.42bc5f8d@loki.starkstrom.lan> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org 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: Mon, 30 Oct 2006 02:14:49 -0000 > ... 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 released because the link count has become zero. At that point, we by definition are only wiping out data which is eligible to be overwritten by any process that happens to be allocating space on the same filesystem, and which can no longer be read by "normal" filesystem operations, anyway. In this interpretation, "rm -P" when the link count exceeds 1 is an erroneous command. I'd at least allow rm -P to wipe a file with a non-zero remaining link count only under the same restrictions applied to files that are not writable by the invoker of rm.