On Tue, 19 Mar 2002, Jan Harkes wrote:

>   open("/coda/vol/staroffice/Office52/program/../../..", O_RDONLY_|O_NONBLOC...
>   lseek(3, 0, SEEK_CUR) = 0
>   getdents(3, /* 27 entries */, 7865) = 480
> - close(3) = 0
> + lseek(3, 0, SEEK_CUR) = 512
> + getdents(3, /* 0 entries */, 7865) = 0
> + _exit(-1) = ?

> So it looks like something has changed with the readdir implementation
> in glibc. It doesn't seem like it actually has looked at what size the
> directory had in the first place. Calling getdents until we get a '0'
> response should be the normal operation, I don't know why the first one
> is happy with only one call to getdents, possibly because the userbuffer
> wasn't completely filled.

I can think that the program in the first case has found the entry it was
looking for (it is inside `pwd` as I can suspect) and hence did not scan
the whole directory to the end. (glibc may have done "readahead" in
the second case?)

> The only other reason I can think of is that we return 480 bytes read,
> and the fileposition is at 512

Doesn't it looks like that difference might confuse glibc's readdir()
implementation ? E.g. make it miss some of the dir entries?
Is there a similar count/offset difference on more "traditional"
filesystems?

Regards,
--
Ivan