Messages in this thread | | | Date | Mon, 22 Mar 2004 17:55:31 +0100 | From | Rüdiger Klaehn <> | Subject | Re: File change notification (enhanced dnotify) |
| |
Mike Waychison wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rüdiger Klaehn wrote: > > | > | My original approach assumed that inode numbers were unique, and it > | would have worked with hard links. But I think it is much more important > | to have a mechanism that works for all file systems than to solve the > | problem of hard links. > | > > Inode numbers are guaranteed to be unique on a given filesystem other > than for hard links.. Where is this assumption broken otherwise? > To quote jan harkes, who repiled to my original proposal:
"Inode number are not necessarily unique per filesystem. Any filesystem that uses iget4 can have several objects that have the same inode number. For instance, Coda uses 128-bit file-identifiers and the i_ino number is a simple hash that is 'typically' unique. There are also filesystems that invent inode numbers whenever inodes are brought into the cache, but which have no persistency when the inode_cache is pruned. So the next time you see the same object, it could have a different (unique) inode number."
But I think the current approach is much better anyway since it does work for a single directory and its subdirectories instead of globally like my initial attempt. If you want to catch hard link issues you will have to watch the root of the file system, but that is still not that expensive. And on "sane" file systems that use unique inode numbers in userspace to solve the hard link problem.
best regards,
Rüdiger - 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/
| |