Messages in this thread |  | | Subject | Re: 2.2.19 NFSv3 client breaks fdopen(3) | From | Trond Myklebust <> | Date | 27 Apr 2001 13:11:34 +0200 |
| |
>>>>> " " == 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 - 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/
|  |