Re: NWFS rename() problem

From: Alexander Viro (
Date: Thu Aug 24 2000 - 13:55:19 EST

On Thu, 24 Aug 2000, Jeff V. Merkey wrote:

> > ??? 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!).

OK, I understand your question now.

        * inode does _not_ die when you remove the link, no matter whether
it happens due to rename() or unlink(). It cannot - if the file was opened
it MUST remain alive until the last process closes it. Files are nameless;
name is just one of the references to file. Files are killed when _all_
references disappear. unlink() is a way to remove a "name" reference.
close() is a way to remove a "descriptor" one, munmap() - "mapping" one,
etc. The only special thing about "name" ones is that they are persistent.
That's not Linux-specific in any way - that's how UNIX treats files and
that's what UNIX applications expect.

        * in the kernel killing the file is triggered when both ->i_nlink
and ->i_count reach zero (the former is the amount of "name" references,
the latter - amount of the transient ones).

        * VFS holds a transient reference when it calls ->rename().
It guarantees that the last surviving reference will be a transient one
(i.e. when we kill the last persistent reference we still hold a transient

        * Filesystem code should just decrement the ->i_nlink. Actual
removal will not be triggered at least until the return to VFS.

        Hope that clarifies the situation a bit... You are thinking about
files as named objects. That is wrong - files just are. You need a name to
get to the file, but once you've got it - you've got it. That's how UNIX
is designed, that's what applications rely upon and that's what a lot of
standards mandate.

> > > > > A description of just how rename() is **SUPPOSED** to work would help.

Well - considering the above it's actually not too complex, at least with
respect to inode removal. rename() acts _only_ on names. Removal may be
allowed by it (and may happen immediately after the return), but that's a
separate operation.

> File system "inode"-like records for NWFS consist of a single file
> called the "Directory File" that is comprised of 128 byte records. A

        Single per directory or single per filesystem? IOW, how are
subdirectories implemented?

> 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?

        Quite. What is the entry layout and how much is needed to access
the file contents? You _must_ keep that contents available until the
->delete_inode() is called - mere ->unlink() or ->rename() should not kill
it. And yes,
        fd = open("foo", ...);
        read() or write() on fd
is perfectly legal. Moreover, it makes a lot of sense in many situations,
so it's not a theory - such things are routinely done by applications.

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:14 EST