Assigning a file to a particular inode - SCO

This is a discussion on Assigning a file to a particular inode - SCO ; (I'm not giving a version, because it's a generic question.) is there any way to induce the OS to use a particular inode to store a file? -- _________________________________________ Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us Attorney and Counselor-at-Law http://ziskind.us Economic ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Assigning a file to a particular inode

  1. Assigning a file to a particular inode

    (I'm not giving a version, because it's a generic question.)

    is there any way to induce the OS to use a particular inode
    to store a file?

    --
    _________________________________________
    Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    Attorney and Counselor-at-Law http://ziskind.us
    Economic Group Pension Services http://egps.com
    Actuaries and Employee Benefit Consultants

  2. Re: Assigning a file to a particular inode

    > (I'm not giving a version, because it's a generic question.)
    >
    > is there any way to induce the OS to use a particular inode
    > to store a file?


    This does depend on version to some extent, since there are filesystems
    where inode number is not just an array index. For instance, OSR5's
    "DTFS" uses some function of the file's starting block number (on the
    disk) as the inode number.

    But for traditional Unix style filesystems which do have an array of
    inodes -- which includes most filesystems you might be using on OSR5 or
    UW7...

    There are ways you can do it by editing the filesystem data. I'm not
    going to get into those because they are very filesystem dependent, not
    to mention dangerous.

    To do it with strictly normal filesystem manipulations:

    Start by looking for that inode number. cd to the root of the
    filesystem you'll be working on, and look for a file with that inode
    number. Let's assume the root filesystem, so:

    # cd /
    # find . -mount -inum 12345 -print
    ./opt/K/SCO/TclX/7.3.2d/tcl.tlib

    Since this found a file, the task is easy. We want to preserve that
    file as closely as possible:

    # found=opt/K/SCO/TclX/7.3.2d/tcl.tlib
    # cp -p $found $found.SAVE
    # mv $found /inum.12345
    # mv $found.SAVE $found

    I copied it to a new name, using "-p" to preserve original ownership,
    permissions and time stamps. Then I moved the prize into the root of
    the target filesystem (be careful not to move it to a different
    filesystem, that will lose the inode number). And then I moved the
    copied file back to its original name.

    Now we can work with the captured file:

    # cd /
    # ls -l inum.12345
    -r--r--r-- 1 bin bin 19005 Jul 27 2000 inum.12345
    # ls -li inum.12345
    12345 -r--r--r-- 1 bin bin 19005 Jul 27 2000 inum.12345
    # chown nouser:nogroup inum.12345
    # cat /etc/termcap > inum.12345
    # chmod 654 inum.12345
    12345 -rw-r-xr-- 1 nouser nogroup 152449 May 8 10:41 inum.12345

    So you see we can manipulate the ownership, permissions and content of
    the inode once we've captured a reference to it.

    What if the `find` came up empty? Then create a bunch of empty files,
    e.g.:

    # n=0; inum=0
    # while [ $inum != 12345 ]; do
    touch file.$n
    inum=`ls -i file.$n | awk '{print $1}'`
    done

    Note that this could create a very large number of files (especially if
    the inum you are looking for is large). You cannot delete the files
    until the loop is complete, because most filesystems allocate inode
    numbers for new files from the lowest available number -- you need to
    create files to fill in all the available holes below the target number.
    Also note that the loop could _miss_ the target inode: some other
    process in the system might create a file right at the wrong instant and
    capture the inode you were looking for. So this is something to be done
    under human supervision, not automatically.

    Finally, what if the `find` came up with multiple matches? That would
    happen if the inode you were looking for was hard-linked to multiple
    names:

    # touch foo
    # ln foo goo
    # ls -li foo goo
    33914 -rw------- 2 root sys 0 May 8 10:46 foo
    33914 -rw------- 2 root sys 0 May 8 10:46 goo

    Then you could capture the inode in the same way, but after migrating
    the file to a new inode, you would need to forcibly link it onto the
    other names:

    # cp -p $found $found.SAVE
    # mv $found /inum.12345
    # mv $found.SAVE $found
    # ln -f $found $found2
    # ln -f $found $found3 # etc

    If you didn't do this, those other file references would continue to
    point to the original inode number. Then after you had changed the
    contents, ownership & permissions of the captured inode, the other links
    would show the modified contents, ownership & permissions. Probably not
    what you want.

    Good luck,

    >Bela<


+ Reply to Thread