Re: getdents64 problem

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Jan 23, 2001 at 10:43:17AM +0100, Trond Myklebust wrote:
> >>>>> " " == Jakub Jelinek <jakub@redhat.com> writes:
> 
>      > You're passing that unmodified u64 value to filldir which is
>      > off_t (ie.  signed 32 or 64bit), so IMHO you basically have 2
>      > options, either sign-extend it at cookie assignment time, or
>      > find out if cookie comes from NFSv2 protocol (inherently 32bit)
>      > and sign-extend cookies before passing them to filldir (in both
>      > cases do nothing about NFSv3 cookies).
> 
> No. The correct thing is to not pass cookies outside the NFS
> layer. I'm therefore thinking along the lines of creating a dictionary
> in the inode to allow us to assign 32-bit signed numbers to cookies,
> and hence to use those for filldir/lseek/...
> This has to be done with care, since we cannot assume that the order
> of entries/cookies will be preserved across cache rereads.
> 
> I therefore have 1 question: does glibc make any assumptions about the
> filldir offsets (other than that they are signed and positive)? Do you
> for example expect monotonicity (i.e. that the next entry has an
> offset with a value guaranteed to be larger that of the current
> entry)?

glibc expects just uniqueness and that you're able to lseek to any of the
d_off's unless it is -1LL, in which case next getdents should read the next
dirent entry. But d_off's are visible to other programs, so other programs
might do further assumptions. On the other side, without monotonicity
getdents would end up with pretty weird behaviour (it would change current
file position up and down).

	Jakub