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/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:14 EST