Sounds good to me!
Jeff
Alexander Viro wrote:
>
> On Tue, 30 May 2000, Jeff V. Merkey wrote:
>
> >
> > Here's what I have determined with MKISOFS. MKISOFS will assume that
> > dirs are always sequential, and if it ever gets into a case where:
> >
> > readdir(,20,)
> >
> > and readdir() returns a higher number entry i.e. readdir asks for 20 but
> > gets back 24 instead (a directory may have 20,21,22,24,28, etc. since
> > some of the entries may be unoccupied), then for some odd reason MKISOFS
> > readdir() calls in GLIB will decrement f_pos by 2 (???) and attempt to
> > re-read the directory, which ususally results in a previous entry
> > getting cached twice, which makes MKISFS think the directory is in a
> > loop.
>
> Ugly... I think I see what happens - glibc readdir() is not the prettiest of
> functions to start with, but the real problem is in weird tricks played
> by __getdents64(). Hmm... Alan, what do you think about saying "screw it"
> and adding ->d_type to sys_getdents() output? Basically, glibc getdents()
> tries to expand the output of sys_getdents() inserting the ->d_type field
> and sometimes it means re-reading the last entries (ones that didn't fit into
> the buffer in expanded form). And looks like it screws up in process...
> There were patches floating around and IIRC they looked quite fine.
>
> We might be better off if we began switching over to fts_open() family in
> the userland - for many cases it's much nicer interface...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:26 EST