(Illustration by Gaich Muramatsu)
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, -- IvanReceived on 2002-03-19 10:59:04