On Wed, Jan 03, 2007 at 08:17:34PM +0100, Mikulas Patocka wrote: > > On Wed, 3 Jan 2007, Frank van Maarseveen wrote: > > >On Tue, Jan 02, 2007 at 01:04:06AM +0100, Mikulas Patocka wrote: > >> > >>I didn't hardlink directories, I just patched stat, lstat and fstat to > >>always return st_ino == 0 --- and I've seen those failures. These failures > >>are going to happen on non-POSIX filesystems in real world too, very > >>rarely. > > > >I don't want to spoil your day but testing with st_ino==0 is a bad choice > >because it is a special number. Anyway, one can only find breakage, > >not prove that all the other programs handle this correctly so this is > >kind of pointless. > > > >On any decent filesystem st_ino should uniquely identify an object and > >reliably provide hardlink information. The UNIX world has relied upon this > >for decades. A filesystem with st_ino collisions without being hardlinked > >(or the other way around) needs a fix. > > ... and that's the problem --- the UNIX world specified something that > isn't implementable in real world. Sure it is. Numerous popular POSIX filesystems do that. There is a lot of inode number space in 64 bit (of course it is a matter of time for it to jump to 128 bit and more) -- Frank - 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
