Messages in this thread | | | Date | Thu, 24 Aug 2000 08:31:33 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: NWFS rename() problem |
| |
On Wed, 23 Aug 2000, Jeff V. Merkey wrote:
> > Al Viro, > > I got to the bottom of the problems reported by Steve Hirsch relative to > building Linux from an NWFS root volume. I am not doing an explicit > iget() on the new inode and the Linux VFS is corrupting kernel memory > when it gets back the renamed inode.
Huh? Is it about 2.0, 2.2 or 2.4? What explicit iget()?
> 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.
> 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>
> 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/
| |