Re: simplifying linux_emul_convpath()

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_at_fledge.watson.org      Senior Research Scientist, McAfee Research