2015-08-28 2:40 GMT+02:00 Ken Thomases ken@codeweavers.com:
On Aug 27, 2015, at 5:05 PM, Matteo Bruni matteo.mystral@gmail.com wrote:
A "safer" option would be to store the position in the fd unchanged but reserve two values (-1 and -2?) for the '.' and '..'. I'm not sure that's entirely safe but I don't see anything better.
Negative values are rejected by lseek() with EINVAL. (Didn't actually try it, but the man page says so and the kernel code seemed to agree. ;)
Empirical tests agree too, lseek(fd, -1, SEEK_SET) returns -1 i.e. error and a subsequent lseek(SEEK_CUR) gives a different value ;)
We would need to treat offset 0 as indicating that the next entry to be read is ".". OFF_MAX - 1 would indicate that the next entry to be read is "..". OFF_MAX - 2 would indicate that we should seek to 0 and read real entries. Or something like that.
I think we should not use OFF_MAX itself as a magic value. In my testing, the NFS driver sets the position to that at EOF. Of course, that raises the possibility that there are other special values that we'll collide with.
Yeah, that's a concern. Actually there is another possibility though. We could swap the "." and ".." entries with the first two entries returned from getdirentries(), in the same vein as read_directory_getdents(). That should work but I'm not sure it's much of an improvement overall. Also it looks like HFS+ at least lists directory entries in-order and it would be somewhat unfortunate to lose that "feature".
I'm attaching a v2 of the patch with your points addressed. I think I'll also try to come up with an alternative version following the aforementioned approach and see how ugly it looks like compared to this...