> > You mean POSIX compliance is impossible? So what? It is possible to > > implement an approximation that is _at least_ as good as samefile(). > > One really dumb way is to set st_ino to the 'struct inode' pointer for > > example. That will sure as hell fit into 64bits and will give a > > unique (alas not stable) identifier for each file. Opening two files, > > doing fstat() on them and comparing st_ino will give exactly the same > > guarantees as samefile(). > > Good, ... except that it doesn't work. AFAIK, POSIX mandates inodes > to be unique until umount, not until inode cache expires :-) > > IOW, if you have such implementation of st_ino, you can emulate samefile() > with it, but you cannot have it without violating POSIX. The whole discussion started out from the premise, that some filesystems can't support stable unique inode numbers, i.e. they don't conform to POSIX. Filesystems which do conform to POSIX have _no need_ for samefile(). Ones that don't conform, can chose a scheme that is best suited to applications need, balancing uniqueness and stability in various ways. > > 4 billion files, each with more than one link is pretty far fetched. > > Not on terabyte scale disk arrays, which are getting quite common these days. > > > And anyway, filesystems can take steps to prevent collisions, as they > > do currently for 32bit st_ino, without serious difficulties > > apparently. > > They currently do that usually by not supporting more than 4G files > in a single FS. And with 64bit st_ino, they'll have to live with the limitation of not more than 2^64 files. Tough luck ;) Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
