> > There's really no point trying to push for such an inferior interface > > when the problems which samefile is trying to address are purely > > theoretical. > > Oh yes, there is. st_ino is powerful, *but impossible to implement* > on many filesystems. 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(). > > Currently linux is living with 32bit st_ino because of legacy apps, > > and people are not constantly agonizing about it. Fixing the > > EOVERFLOW problem will enable filesystems to slowly move towards 64bit > > st_ino, which should be more than enough. > > 50% probability of false positive on 4G files seems like very ugly > design problem to me. 4 billion files, each with more than one link is pretty far fetched. And anyway, filesystems can take steps to prevent collisions, as they do currently for 32bit st_ino, without serious difficulties apparently. 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
