Re: NWFS rename() problem

From: Jeff V. Merkey (
Date: Thu Aug 24 2000 - 12:10:58 EST

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?


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

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