Messages in this thread | | | Date | Thu, 24 Aug 2000 14:03:34 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: NWFS rename() problem |
| |
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/
| |