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