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.
I trapped calls to readdir() in the VFS and the call to readdir(3) in
GLIB. MKISOFS is calling readdir(3) correctly, but it appears that GLIB
will get confused as to where it actually is in the directory. I am
also seeing inconsistent recurring calls to readdir() in the VFS when
this happens that are not always congruent (i.e. readdir() in the VFS
will ask for 18 entries, then as for 22, then ask for 24, etc. which
seems somewhat buggy.
Bottom line is that MKISOFS is caching inode numbers, so if anyone ever
deletes a file from beneath it while running across an FS tree, then it
will break. Suffice to say that any FS that allows holes in f_pos calls
to readdir() seems to be troublesome for MKISOFS on 2.4.
Other than getting VERY agressive with POSIX readdir() behaviors, I see
no other fix for this than to implement POSIX readdir() to the letter.
Seems to work. NCPFS and SMBFS still seem to have some problems when
they generate their own ino's. So long as whatever tree you are working
on is not being shared by mulitple callers (which causes any seek to '0'
to reshuffle the directory ordering), it seems to work OK with
everything.
:-)
Jeff
"Jeff V. Merkey" wrote:
>
> Alan/Al,
>
> I looked through his code, and he is creating a directory hash in memory
> and caching inode numbers. The code implementation looks problematic
> since someone could delete and recreate a file underneath him, and
> render his cache stale. I am attempting to track down the bug in his
> code. It appears that he is doing this in case he encounters hard
> links/soft links and needs to know how/when to intelligently handle
> these two cases. The implementation is convoluted, and I can see where
> his method of handling readdir() calls may break if he gets a 1,2,3,5,11
> sequence (which he does not appear to expect).
>
> I will implement the nts_open(3) call specified by Al and try again.
> I'll update when I've got a version of MKISOFS that doesn't break.
>
> :-)
>
> Jeff
>
> Alan Cox wrote:
> >
> > > It functions correctly with EXT2, but is also brokwn on NKFS, NCPFS< and
> > > SMPFS -- gives similiar errors. Looks like more POSIX/GLIB crap.
> >
> > NCP/SMB regenerate inode numbers themselves, including reusing them.
> > It only guarantees uniqueness on open files.
> >
> > Alan
> >
> > -
> > 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/
>
> -
> 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/
-
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