Messages in this thread | | | Date | Thu, 24 Aug 2000 13:49:20 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: NWFS rename() problem |
| |
Alexander Viro wrote: > > > > * 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 > one). > > * Filesystem code should just decrement the ->i_nlink. Actual > removal will not be triggered at least until the return to VFS.
Yes. I am removing the file in these cases. So that part sounds like it's there.
> > 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?
A single directory file per volume (like an inode table, except mine can grow dynamically), and the file is viewed as a sequential list of 128 byte records numbered 0...n. Files and Subdirs are identical in terms of how they are layed out. Each 128 byte record has a unique number and contains a parent link back to it's directory. '0' is assumed to be the root volume directory and all other directories in NWFS use the record number of the relative position of a particular 128 byte record in the volume directory file as the directory number.
> > > 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,
Each "root" namespace record has a fat chain head or suballocation index to indentify where the fat or suballoc chain starts for the data storage for a file. Subdirs do not have a fat chain head in the directory file. A "file" in NWFS can be a linked list of directory records with the "root" record holding the file data fork. If a MAC namespace is present, the MAC record in this chain may also contain a fat chain head in it's directory record.
> fd = open("foo", ...); > unlink("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.
It sounds like inode numbers are arbitrary, and so long as I have cached a hash structure in the inode (which I do), I can just make up inode numbers for files (provided they are unique), and use the inode->generic_ip pointer to access the actual directory number.
Is this correct?
Jeff
> > - > 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/ - 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/
| |