lkml.org 
[lkml]   [2007]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Finding hardlinks
    On Wed, Jan 03, 2007 at 08:31:32PM +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)
    >
    > If the filesystem was designed by someone not from Unix world (FAT, SMB,
    > ...), then not. And users still want to access these filesystems.

    They can. Hey, it's not perfect but who expects FAT/SMB to be "perfect" anyway?

    >
    > 64-bit inode numbers space is not yet implemented on Linux --- the problem
    > is that if you return ino >= 2^32, programs compiled without
    > -D_FILE_OFFSET_BITS=64 will fail with stat() returning -EOVERFLOW --- this
    > failure is specified in POSIX, but not very useful.

    hmm, checking iunique(), ino_t, __kernel_ino_t... I see. Pity. So at
    some point in time we may need a sort of "ino64" mount option to be
    able to switch to a 64 bit number space on mount basis. Or (conversely)
    refuse to mount without that option if we know there are >32 bit st_ino
    out there. And invent iunique64() and use that when "ino64" specified
    for FAT/SMB/... when those filesystems haven't been replaced by a
    successor by that time.

    At that time probably all programs are either compiled with
    -D_FILE_OFFSET_BITS=64 (most already are because of files bigger than 2G)
    or completely 64 bit.

    --
    Frank
    -
    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/

    \
     
     \ /
      Last update: 2007-01-03 21:29    [W:4.214 / U:0.504 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site