Hi,

In there is another thing in this disucssion that doesn't make sense to me.
A POSIX compliant implementation of getwd (getcwd) may NOT use the inode
numbers in directories returned by readdir.  It MUST use those obtained from
stat (see the POSIX spec).

The glibc getwd code will do readdir solely to obtain the names, not to
obtain the inode numbers, which it gets by doing a stat call on each name in
the directory.

For a while, Coda just put -1 as the inode number in the directory container
files, and things worked fine.

For the lookup upcall it is very important that the correct fid is returned
(see Jan's message) and both the user level code and the kernel code must do
correct fid <--> inode mapping.  This is not desirable and will change with
Jan's new implementation.

- Peter -



> What operating system and version of venus are you using?

Sorry, I forgot. It's Linux 2.2.10 and linux-coda-5.2.3-linux2.2.9.tgz
as coda module.

> So when your userspace code sets up the directory data, it has to pick
> the fids for all directory entries, and can then fill in the correct
> inode numbers in the directory structure.

OK. I'm beginning to understand: the value of 'va_fileid' must match
the inode number calculated from the Fid.

But what is still not clear: when venus sets up the local directory
structure, does it choose the Fids so that the calculated inode number
matches the actual inode number of the local file? How can it do this?

Thanks,
Miklos