fs/readdir.c:fillonedir() vs. fs/readdir.c:filldir()

[William Taber]

Hi folks,

In porting our file system to Linux, we discovered a discrepancy in the
old and new method of returning directory entries to programs.  This
exists in 2.2.x and 2.4.x kernels (and maybe older ones too?)

fs/readdir.c:filldir(), used by most (?) programs, expects the
directory entry provided by the file system to have the d_offset field
set to the offset of the *current* entry, and it plays games to use the 
next entry's offset to return to the user for the current directory
entry's d_offset field.

fs/readdir.c:fillonedir(), used by (apparently?) ancient
programs/libraries, expects the directory entry provided by the file
system to have the d_offset field set to what should be sent to the
user, i.e. the offset of the *next* entry.

These two are mutually incompatible interpretations of how to fill in
directory entries, and there's no way for the file system to tell which
one is going to be used when its file_ops->readdir() function is
invoked.

I would guess this is rarely a problem because fillonedir() is rarely
used, and it should be fixed to use the readdir results as expected by
filldir().  But I'm not sure it's possible to find/save enough state to
do this right, as the old readdir gets a single entry per syscall.

Perhaps the readdir interface to the file systems should expect the file
system to provide the proper d_offset field in each entry (holding the
offset of the following entry), then filldir() and sys_getdents() can
avoid all the mucking about with d_offset?

Will Taber

+---------------------------------------------------------------------+
| Will Taber                                                          |
| Software Engineer, CMBU                 E-mail  [e-mail] |
| Rational Software Corporation           Phone:  [phone]        |
| 20 Maguire Road, Lexington, Mass. 02421                             |
+---------------------------------------------------------------------+