On Wed, Sep 03, 2003 at 03:18:55PM +0200, Matthias Drochner wrote:
> M.Drochner_at_fz-juelich.de said:
> > There are however 2 serious deviations from standard (BSD) behaviour
> > in the dirent/readdir code. 
> 
> looked a bit deeper into the matter, it doesn't look that serious anymore.
> 
> > wrong is that the d_type fields are zero
> 
> That's indeed a bug and should be fixed. (That Linux doesn't get it
> right is no excuse.)

But zero is correct.

    #define DT_UNKNOWN 0

And we really don't know what the type of the entry is, because the Coda
directories that are fetched from the server only contain name <>
file-identifier mappings. The type can only be obtained by separately
fetching the file attributes for all objects that are referred to by
directory entries.

This is why DT_UNKNOWN exists in the first place, Coda is not the only
network filesystem that doesn't have file attribute information packed
along with the directory data. And even some on-disk filesystems do not
automatically embed this information to avoid the seeking around the
disk to extract any unknown data from inodes.

> It is probably possible to fix up the dirents either in venus or
> in the kernel by calling stat() on each directory entry. Might
> have perfomance implications.

Yes, and quite serious performance implications because in that case we
would be forced to pull mostly unused file objects into the cache and
as a result throw out possibly more interesting ones when we really only
want to read the directory data for path traversal purposes.

> > that the first 2 entries are
> > not "." and ".."
> 
> I got told that POSIX does not require any ordering of directory
> entries; applications which make assumptions here are wrong.
> After fixing BSD "make" accordingly, I can build kernels in my
> coda tree.

Correct, it is a quite common assumption though, just like the nlink
count of a directory being 2 + #subdirectories which is not necessarily
valid for a coda directory with embedded mountpoints. The mountpoint
is technically special symbolic link and the mounted directory doesn't
have a direct reference to the parent. As a result the directory link
count only represents the real subdirectories and not the 'mounted
directories' which confuses f.i. GNU find.

Jan