Messages in this thread | | | Date | Thu, 24 Aug 2000 11:10:58 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: NWFS rename() problem |
| |
Alexander Viro wrote: > > > I have a question here. In rename() is it always assumed that the > > target must do a read_inode() via iget() after the file is mv'd? What > > about the case where you are simply renaming a file in the same > > directory? Is it always the case that rename will remove the old inode > > and substitute the new one even if you are just renaming a file in the > > same directory? This is the case causing all the problems. > > Inode or directory entry? If the target exists you _must_ remove the old > one, indeed. >
Linux 2.2.17 and 2.4.0-test7
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).
> > 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 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?
Jeff
> > > The Linux rename() semantics are somewhat confusing -- last bug and NWFS > > will run as a root filesystem in Linux and we can ship our Linux > > Distribution. I fixed the bamp() bugs reported at the same time, so the > > page cache is now working and apps run ok. Runs very fast too.... - 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/
| |