Messages in this thread | | | Date | Thu, 28 Dec 2006 08:22:44 -0500 | From | Jeff Layton <> | Subject | Re: Finding hardlinks |
| |
Benny Halevy wrote: > > It seems like the posix idea of unique <st_dev, st_ino> doesn't > hold water for modern file systems and that creates real problems for > backup apps which rely on that to detect hard links. >
Why not? Granted, many of the filesystems in the Linux kernel don't enforce that they have unique st_ino values, but I'm working on a set of patches to try and fix that.
> Adding a vfs call to check for file equivalence seems like a good idea to me. > A syscall exposing it to user mode apps can look like what you sketched above, > and another variant of it can maybe take two paths and possibly a flags field > (for e.g. don't follow symlinks). > > I'm cross-posting this also to nfsv4@ietf. NFS has exactly the same problem > with <fsid, fileid> as fileid is 64 bit wide. Although the nfs client can > determine that two filesystem objects are hard linked if they have the same > filehandle but there are cases where two distinct filehandles can still refer to > the same filesystem object. Letting the nfs client determine file equivalency > based on filehandles will probably satisfy most users but if the exported > fs supports the new call discussed above, exporting it over NFS makes a > lot of sense to me... What do you guys think about adding such an operation > to NFS? >
This sounds like a bug to me. It seems like we should have a one to one correspondence of filehandle -> inode. In what situations would this not be the case?
-- Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |