I have been tracking through a bug with Coda where, basically, getdents(2) is not returning all the directory entries. The files exist in the directory but do not show up on a globbed listing. After some digging I found that things ended up in ufs_readdir() which was terminating early due to a bad dirent.
What is happening is the userland part of Coda, venus, manufactures a the dirents for a directory when a read request comes up from the kernel. It has code to carefully avoid a dirent spanning a DIRBLKSIZ boundary by padding a dirent near the boundary. This data is returned to the kernel for processing. Where things come unstuck is DIRBLKSIZ is defined in /usr/include/dirent.h as 1024 bytes, inside the kernel ufs code sys/ufs/ufs/dir.h DIRBLKSIZE is set to DEV_BSIZE which is 512 bytes. This means that venus can produce a block of dirents that finish before the 512 byte mark, the kernel code tries to align back to a 512 byte boundary and fails to find a valid dirent - the fact that ufs_readdir() exits gracefully rather than causing a panic is more by luck than anything else. To fix it I think I have the following choices: 1) Patch venus so it ignores the userland DIRBLKSIZ and, instead, uses DEV_BSIZE (if available) or just hard code in 512 bytes as the dirent block size. 2) Change DIRBLKSIZ in dirent.h so it matches the kernel 3) Fix mount_coda so it updates the um_dirblksiz to match userland. I have done 1 to test and a previously misbehaving directory does seem to work a lot better. I see both 1 & 3 being a bit dangerous in the event that if the definitions change again. I am not entirely sure about the implications of 2 - a quick look only showed up initdir.c in libc using the define but there may be others. Does anyone have any views on which approach would be the most correct way of fixing this? -- Brett Lymn "Warning: The information contained in this email and any attached files is confidential to BAE Systems Australia. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is expressly prohibited. If you have received this email in error, please notify us immediately. VIRUS: Every care has been taken to ensure this email and its attachments are virus free, however, any loss or damage incurred in using this email is not the sender's responsibility. It is your responsibility to ensure virus checks are completed before installing any data sent in this email to your computer."
