Christian, Thanks for the in-depth analysis. I'm not familiar with the NFS code, so I'm confused about how it is handling the "cookies". As JFS returns the entries via "filldir", each entry's position is correctly returned. But when we have exhausted all entries, f_pos is set to -1. I don't know why NFS would associate this with the last returned entry, since I understand it to be associated with the next entry which would be returned in a subsequent call to readdir.
Would you happen to know if -1 is special? Would returning -2 make things work, or does it really need to be a positive number? I'm not sure about the -D_FILE_OFFSET_BITS=64. This makes me think that glibc doesn't like negative offsets in readdir. This concerns me because JFS will eventually use negative offsets when the index gets large enough to use the high bit. However, I still don't know why the -1 gets associated with the last valid entry. Christian Schmidt wrote: > > Now it's 3am, another sunday is gone, and - the -1 is it. If I change it > in the kernel NFS code to be a positive integer, everything is fine - > but still the question is who to blame. > The JFS folks that push their endofdirectory marker up? > The NFS folks that set their cookies to some arbitrary values from the > FS below (or possibly cause the trouble in their code)? > Or is it just a misinterpretation in glibc? We'll see next weekend... > > Regards, > Christian > > PS: NFS v3 seems not to have this problem... -- David Kleikamp IBM Linux Technology Center _______________________________________________ Jfs-discussion mailing list [EMAIL PROTECTED] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
