[lkml]   [2001]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.2.19 NFSv3 client breaks fdopen(3)
>>>>> " " == Matthias Andree <> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.043 / U:1.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site