This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: getdents64 problem


On Mon, Jan 22, 2001 at 11:59:51PM -0800, Ulrich Drepper wrote:
> Mogens Kjaer <mk@crc.dk> writes:
> 
> > I guess a lot of programs have this construction
> > 
> > x=opendir("path");
> > while((y=readdir(x))!=NULL)
> > {
> >   do something
> > }
> > closedir(x);
> > 
> > and it would fail silently when reading from an SGI via NFS,
> > as one seldomly checks for errors when readdir has return NULL.
> 
> This is why everybody will have to compile programs with
> _FILE_OFFSET_BITS=64.  Did you ever notice that all GNU programs
> already do this?

Actually, are you talking NFSv2 or NFSv3 to the SGI server?
If you're talking NFSv2 which passes around 32bit cookies as far as I can
see, then this is definitely a kernel bug (at least in my 2.4-testsomething
tree nfs_decode_dirent does
         entry->cookie     = ntohl(*p++);
which is wrong (dunno if that changed since then), because ntohl gives
unsigned result). If you are speaking NFSv3 and the SGI server is passing
0, 0xffffffff over the network instead of 0xffffffff, 0xffffffff, then it
would be a bug in SGI server (but you could still try to force NFSv2).

I don't think it would be necessary to use only LFS compiled programs
(especially for NFSv2 which does not support more than 2GB anywhere).

	Jakub

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]