Date: Wed, 14 Jan 2004 16:50:18 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: harti@freebsd.org Cc: current@freebsd.org Subject: Re: simplifying linux_emul_convpath() Message-ID: <Pine.NEB.3.96L.1040114164938.49872I-100000@fledge.watson.org> In-Reply-To: <20040114221135.V15441@beagle.fokus.fraunhofer.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040114164938.49872I-100000>