> First of all I would like to know what exactly is the meaning of the > 'offset' parameter of filldir and whether it is used somewhere?
The user visible use of offset, is when you do a telldir(), store the returned offset, and later do a seekdir(). Also you can directly use dentry->d_off as an offset for seekdir(). All this is very rarely used, I never seen actual application code to do either. > Unlike ext2, our directories are not easily read sequentially and > this value (copied by filldir to dirent->d_off) seems to be quite > useless outside our fs code. Actually the 'offset' parameter of filldir is copied into the _previous_ dirent->d_off. For the last dirent returned in a getdents() system call, dirent->d_off is set to file->f_pos. So basically the rule is, to store current directory offset (whatever you may choose that to be) in file->f_pos, send current file->f_pos as the offset parameter of filldir, and after this update file->f_pos to the offset of the next entry. > Related question is what is the correct behaviour of readdir in case > of user's seeking in the directory? If I understand correctly, in case > of ext3 (indexed directories), when seeking is detected, readdir > starts reading from the directory beginning again. If the filesystem can determine from the supplied offset to readdir() where to continue the directory reading, it need not start from the beginning. SUS says about this: If a file is removed from or added to the directory after the most recent call to opendir() or rewinddir(), whether a subsequent call to readdir() returns an entry for that file is unspecified. > The last is about concurrency. How is solved problem when a directory > is read by readdir and between two readdir calls the same directory is > changed? Look at fs/libfs.c for example. It uses a 'cursor' to mark where it's currently in the directory reading. I can imagine other methods. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
