On Thu, 24 Aug 2000, Jeff V. Merkey wrote:
> If I remove the old one, I assume that the inode passed as new_inode is
> for the current file that exists, and if the file does not exist, who
> kick starts the iget() call to propogate to read_inode() -- the vfs? If
> so, then is it ok to just update it (seems to be what happens here).
??? Wait-a-bloody-minute, but VFS doesn't pass _any_ struct inode * to
->rename() since 2.1.something.
> > > A description of just how rename() is **SUPPOSED** to work would help.
> >
> > Erm... Depends on the version. How about some context?
> > <horrible suspicion>
> > Are you, by chance, using directory entry location as inumber?
> > </horrible suspicion>
>
> This is a very astute observation. Yes, I am and it may change if I end
Then you are screwed. Big way. BTDT and it still aches. That's what msdosfs
and VFAT used to do and boy, what a shitload of races they had... Fixing
took 4 months and it was not pretty. Probably I can help you with that
mess.
> up creating a new entry during rename. I guess I should update
> inode->i_ino if it changes underneath the inode in the vfs above?
You should have ->i_ino
a) constant over the lifetime of in-core inode
b) unique. And that includes opened-but-unlinked inodes too.
And yes, in case of filesystem that lacks such invariants it is painful.
Please, describe the fs layout - hopefully the trick I've used for
FAT-derived filesystems will work, but I need more details.
For general description of the trick (badly written - sorry) see the
posting to fsdevel back in May '99...
<looking in archives> Aha, here it is:
http://kernelnotes.org/lnxlists/linux-fsdevel/lv_9905/msg00030.html
For more specific help - give me description of fs layout.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:13 EST