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
