Re: NWFS rename() problem

From: Alexander Viro (
Date: Thu Aug 24 2000 - 13:03:34 EST

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

> 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:

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
Please read the FAQ at

This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:13 EST