Re: [RFC,PATCH] libfs dcache_readdir() and dcache_dir_lseek() bugfix

[jblunck@suse.de]

On Fri, Nov 04, Jörn Engel wrote:

> On Fri, 4 November 2005 16:11:04 +0100, jblunck@suse.de wrote:
> > 
> > True. Seeking to that offset should at least fail and shouldn't stop at the
> > new entry. But SuSV3 says that the offset given by telldir() is valid until
> > the next rewinddir().  This is no problem for directories that can only grow.
> > I tried to implement some kind of deferred dput'ing of the d_child's but that
> > was too hackish and was wasting memory. So the best thing I can do now is fail
> > if someone wants to seek to an offset of an already unlinked file.
> 
> Does that mean that, to satisfy the standard, you'd have to allow the
> seek, but return 0 bytes on further reads, as you're already at (or
> beyond, whatever) EOF?

No. To satisfy the standard, it would be necessary to let the seek succeed and
to return the already unlinked dentry or the next dentry (this is
unspecified). I think we should return the next dentry, therefore I let the
seek fail (seekdir() doesn't even have a return value) and the cursor/f_pos is
still at the old offset.

The real problem is this IMHO:
...
telldir() = a
...
telldir() = b
readdir() = foo.txt
unlink(foo.txt)
seekdir(a)
seekdir(b)
readdir() = ???

With my patch the seekdir(b) doesn't find the offset and is placing the cursor
at the end of the directory. In my understanding of the SuSV3 this should be
possible and should return either "foo.txt" or the next entry after
"foo.txt". I don't see any chance how I can implement that.

Regards,
	Jan Blunck

-- 
Jan Blunck                                               jblunck@suse.de
SuSE LINUX AG - A Novell company
Maxfeldstr. 5                                          +49-911-74053-608
D-90409 Nürnberg                                      http://www.suse.de