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

[Rob Landley <rob@landley.net>]

On Friday 04 November 2005 05:51, Al Viro wrote:
> On Fri, Nov 04, 2005 at 12:38:51PM +0100, jblunck@suse.de wrote:
> > This patch effects all users of libfs' dcache directory implementation.
> >
> > Old glibc implementations (e.g. glibc-2.2.5) are lseeking after every
> > call to getdents(), subsequent calls to getdents() are starting to read
> > from a wrong f_pos, when the directory is modified in between. Therefore
> > not all directory entries are returned. IMHO this is a bug and it breaks
> > applications, e.g. "rm -fr" on tmpfs.
> >
> > SuSV3 only says:
> > "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_r() returns an entry for that file is unspecified."
>
> IOW, the applications in question are broken since they rely on unspecified
> behaviour, not provided by old libc versions.

Are you sure that's the problem?

Directory starts with 26 files named A-F.
Reading through directory starts at A, makes it to J (position 10).
File B gets deleted.
directory reading continues at new position 11, which is now L.

So directory read returns A-J, L-Z, and never returns K even though K didn't 
change.

The "that file" mentioned by SuSv3 above would be _B_ here.  Not K.  K didn't 
change.

That said, I'm pretty sure it's the old libc behavior that's defective.  If a 
new entry B' had been inserted instead, the directory traversal would have 
seen L twice.  Iterating by position is just wrong...

Rob
-
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/