>>>>> " " == Matthias Andree <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
