Al,
rename() is fine. I've also fixed the symlink thing as well (there were
several other problems as well here when I started hashing the fat chain
heads), and I appreciate you finding these other holes. I'll fix them
ASAP. There's a newer version that has tons of fixes, including
auto-repair of volumes and fats during mount). What would really be
helpful, and would leverage your considerable expertise, would be to
look at DIR.C and see if you think I'm doing the POSIX stuff right. I
am getting a "circular directory" error when I run MKISOFS to build ISO
images from an NWFS volume. I've put in code to see if I am generating
duplicate inode numbers, and I am not, so the only thing I can think
here is that I've got another POSIX bug. The functions called by DIR.C
are all in HASH.C BTW.
Also, see comments below.
:-)
Jeff
Alexander Viro wrote:
>
> On Thu, 11 May 2000, Jeff V. Merkey wrote:
>
> > I have only the variable page size mapping layer left to regress and a
> > MKISOFS bug remaining before submitting diff's to Alan/Linus for
> > 2.0/2.2/2.4. Everything else (less HFS integration) has been
> > completed. IA64 will be posted after I test it on an IA64 box (which
> > Intel has kindly offered to make available for us to test on end of this
> > month).
>
> Ugh... Jeff, I've looked at your code (my apologies for brainfart re RPC -
> I've got coffee and I'm back to sanity) and there are some places that look
> fishy.
> 1) // if somebody already freed the directory record for this ino,
> // then just return.
> in read() sounds *wrong*. If it means what it seems to mean it
> breaks the semantics of unlink() - unlink() should have no effect
> on later read() if the file had been opened prior to it.
> POSIX-mandated, yodda, yodda and there is a lot of software relying
> on that.
readpage() or file_read()? Is this the code in FILE.C?
> 2) As for the symlinks... What's wrong with nwfs_readpage(), why do
> you bother with the NWReadFile() thing? If it's just a matter of
> NUL-termination - call the nwfs_readpage() and put '\0' into the
> right place after that.
Ditto. I'll correct this.
> 3) nwfs_rename() looks deadlocky - you lock two objects and do not
> seem to care about the order of locking. And you are doing that
> very close to the entry, so it doesn't look like some other
> serialization may save you here.
This is OK -- I am observing lock ordering here, though I admit what's
there should definately be cleaned up. I have fine grained locking in
the FS -- I need a reader/writer lock instead of a semaphore here.
> 4) Ditto for rmdir() - same story, same potential problem.
>
> -
> 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 : Mon May 15 2000 - 21:00:20 EST