On Tue, Mar 19, 2002 at 11:37:50AM +0100, Steffen Neumann wrote:
> I have straces of soffice with both
> /net and user on coda, but debugging that 
> is somewhat beyond me. 

I just opened it with vimdiff (tkdiff would work too) and looked at the
changes. One change, which is interesting but minor is that 2.4.18 seems
to run the child first after a fork. Most of the smaller differences are
caused by this.

I did find something interesting around line 1960/1953

  lstat("/coda/vol/staroffice/Office52/program/../..", {st_mode=S_IFDIR|0777...
  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) = ?
- lstat("/coda/vol/startoffice/Office52/program/../../..", {st_mode=S_IFDIR|...
- open("/coda/vol/staroffice/Office52/program/../../../..", O_RDONLY_|O_NONB...

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'm also not sure why it is calling lstat on the parent of the directory
it is about to open, or maybe the logic here is the other way around and
it tries to discover whether the directory we were just reading got
modified.

I'd like to see the getdents results of reading that directory, it looks
like system call wise we're doing the right thing, return the number of
bytes read and return '0' when we hit the end of the directory. Maybe
the directory contents has something strange.

The only other reason I can think of is that we return 480 bytes read,
and the fileposition is at 512, but if that is really considered the
'fatal problem', why would another getdents be called.

Jan