Messages in this thread | | | Date | Thu, 24 Aug 2000 12:12:46 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: NWFS rename() problem |
| |
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/
| |