[lkml]   [2000]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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?


    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to
    > Please read the FAQ at
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.030 / U:9.784 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site