Re: 2.2.19 NFSv3 client breaks fdopen(3)

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Matthias Andree <matthias.andree@stud.uni-dortmund.de> writes:

     > On Thu, 26 Apr 2001, Trond Myklebust wrote:
    >> Please note that if glibc is checking this return value, it
    >> will still screw up if file->f_pos > 0x7fffffff, which can and
    >> does happen against certain servers (particularly IRIX).

     > Do servers have directories that are this large? It'd take
     > quite some files to get a directory itself (not counting its
     > files) exceed 2 GB, wouldn't it?

Check out IRIX. The xfs filesystem uses full 32 or 64 bit unsigned
cookies on all directories whether they are short or long.

Bottom line: you should not confuse directory cookies with offsets.

    >> As I've said before: it is a bug for glibc to be relying on
    >> seekdir if we want to support non-POSIX compliant filesystems
    >> under Linux.

     > There's no seekdir. No telldir. Just a "get ofile current
     > position".

Same difference.

     > Meanwhile, I took a glance at fileops.c and iofdopen.c of the
     > glibc source RPM that SuSE 7.0 uses, there is no seekdir like
     > stuff involved, it's just that when glibc rolls the dice to get
     > a FILE structure filled, it gathers the current file position,
     > since someone might have called read before fdopen. I think
     > that's legitimate.

     > No seekdir. (would be pointless since seekdir does not return a
     > value) Not even telldir. Just plain fdopen. Is a plain fdopen
     > supposed to fail just because some clients don't understand the
     > semantics some server uses; not even considering who's fault it
     > might be? Certainly not.

File position for an NFS directory can take any 32bit or 64bit
unsigned value. This has been the case on Linux since before glibc2
was even a glimmer in Ulrich Drepper's eye.

Cheers,
   Trond