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

[Miklos Szeredi <miklos@szeredi.hu>]

> > 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?
> 
> Sounds quite ugly and it would be nice if this wasn't necessary.

The directory position not _on_ an entry, but _between_ two entries.
So it doesn't matter if the next entry is removed, the offset stays
perfectly valid.

If there doesn't remain any entries after the position, readdir should
return EOF.  Otherwise it should continue reading normally.

What SUS doesn't specify is what happens entries added between
opendir() and before rewinddir().

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/