From owner-freebsd-current@FreeBSD.ORG Wed Jan 14 13:52:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 777A416A4CE; Wed, 14 Jan 2004 13:52:13 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0982343D41; Wed, 14 Jan 2004 13:52:11 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0ELoSUd054027; Wed, 14 Jan 2004 16:50:28 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0ELoIBT054019; Wed, 14 Jan 2004 16:50:18 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 14 Jan 2004 16:50:18 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: harti@freebsd.org In-Reply-To: <20040114221135.V15441@beagle.fokus.fraunhofer.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Don Lewis cc: current@freebsd.org Subject: Re: simplifying linux_emul_convpath() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:52:13 -0000 On Wed, 14 Jan 2004, Harti Brandt wrote: > RW>So what ends up happening is what Coda and Arla do: take the 96-bit unique > RW>identifier (viceid or fid), hash it to a somewhat unique value, and stick > RW>the result in the vattr returned by VOP_GETATTR(). And sometimes > RW>applications just get confused. Of course, many of those applications were > RW>quite capable of getting confused before -- unless you hold a file open, > RW>you can't prevent its inode number from being reused if the file is > RW>deleted and a new one created. > > The problem is with archivers. Posix guarantees that if the device and > the inode are equal then its the same file. If they are different its > another file. If two different files have the same device/inode > archivers that can store hard links will think that this is a hard link > and will store only one file. If they are clever they will check the > nlink is greater 1. But this doesn't help if both files have an nlink > > 1. > > So backups of these larger file systems will likely be hosed. This can end up with incorrect operation on a live file system anyway: nothing says the file with inode 400 can't be deleted, then reused as the archiver runs, and then count as a false positive... :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research