On Wed, 20 July 2005 11:11:01 -0700, Chris Wedgwood wrote: > On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote: > > > To my understanding, you can lseek to any "proper" offset inside a > > directory. Proper means that the offset marks the beginning of a > > new dirent (or end of file) in the interpretation of the filesystem. > > But you can never tell where these are in general.
Correct. Any filesystem can have any definition of proper. > > Userspace doesn't have any means to figure out, which addresses are > > proper and which aren't. Except that getdents(2) moves the fd > > offset to a proper address, which likely will remain proper until > > the fd is closed. > > I don't see why or how this can be true in general (it might be, but I > don't see how myself). If we are half way through scanning a > directory and people start messing with it we could end up somewhere > bogus (in which case f_op->readdir I guess is expected to try and do > something sane here?) If you read a large directory, it will take you quite a while to go through the thousands of getdents() invocations. Someone messing with the directory meanwhile should be expected and shouldn't cause userspace to get complete garbage. If userspace doesn't learn about all new dirents, that's fine. If it receives old ones, that were since deleted, that's fine. But under no circumstances should you hand out garbage. Ext2, iirc, solves this problem by never shrinking directories. Old dirents can be invalid and won't get passed to userspace anymore. But they don't move around. Hence, a linear read of the directory gives you exactly above properties. > > Reopening the same directory may result in a formerly proper offset > > isn't anymore. > > For that to be the case where is the state kept to ensure your current > offset is valid? Depends on the fs. Ext2, as seen above, only needs file->offset as state. But image a questionable optimization for an uncommon case. Whenever the last reader or an ext2 directory closes the fd, it is safe to shuffle things around. At this time, a "directory defragmenter" takes the directory and squeezes all holes out of it. The new, repacked directory consumes less space, which is nice. Alternatively, the directory defragmenter could create a new directory, copy all valid contents of the old one over, and new open() on the directory will get the new copy, while old file descriptors still point to the old one. In both cases, what used to be a proper offset in one fd can be complete bogus for another one. And no, I don't want to add directory defragmenters to ext2. It was just a stupid example of what is possible. Jörn -- Linux [...] existed just for discussion between people who wanted to show off how geeky they were. -- Rob Enderle - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
