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 [EMAIL PROTECTED] | | Rational Software Corporation Phone: 781-676-2436 | | 20 Maguire Road, Lexington, Mass. 02421 | +---------------------------------------------------------------------+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
