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/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:14 EST