Alexander Viro wrote:
>
> 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.
You are correct. I think what I was asking was how does an inode in the
vfs get invalidated if rename() asks the FS to remove a previously
exisiting file with the same name. From what you describe, the inode
number will remain constant and the same inode will get re-used (with
the previous inode number -- yikes!).
>
> > > > 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.
File system "inode"-like records for NWFS consist of a single file
called the "Directory File" that is comprised of 128 byte records. A
File consists of a root 128 byte record and can have up to six other
records chained from it (in a single linked chain) with each 128 byte
chained record holding a namespace record. What I am using as the inode
number if the file relative position of the "root" (MS_DOS) namespace
record in the directory file. These nubers are unique for a given
file. If I rename a file or mv it, it is possible for a new set of
linked directory records to get created with a differnt "root" record
relative position. I have been using these numbers as the inode
number. Sounds like this was a bad idea?
:-)
Jeff
>
> 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