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: [PATCH] for glibc-2.2 getdents code


On Wed, Feb 21, 2001 at 07:24:16PM +0100, Jakub Jelinek wrote:
> > If you want to get d_type, use getdents64, but not getdents. It is
> > the same as LFS. You can only get the right information with the
> > right interface.
> 
> But d_type should be completely orthogonal to LFS. It is not present in
> sys_getdents simply because sys_getdents was there before d_type was
> introduced and as userland getdents can call sys_getdents64 to get d_type,
> I have not added sys_newgetdents.

Then add sys_newgetdents. I think it is the right fix.

> IMHO the fix is really simple, if kernel nfs client will cast the offset for
> NFSv2 properly (it goes as 32bit value over the network AFAIC), then the
> problem will go away. And if people are using NFSv3 and the server passes
> d_off's which don't fit into 32bit off_t, then IMNSHO kernel sys_getdents
> should fail on it the same way as glibc getdents does, because it is better
> to give user error than incorrect information (= silently discarded bits
> from d_off).
> 

I don't think it is the issue here. The issue here is the NFS cookie,
which should be opaque to client. The NFS client can use it as offset
to access files as long as it doesn't interpret it. Some NFS server
may set the 32th bit in a 32 bit cookie. That is why the 32bit glibc
getdents fails with the getdents64 system call.


-- 
H.J. Lu (hjl@valinux.com)


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