Re: inode open

[Jason Thorpe <thorpej%shagadelic.org@localhost>]

On Jul 16, 2008, at 3:27 PM, Johnny Billquist wrote:

> Trying to look at MacOS right now, but can't find a function to open  
> a file by inode number. What's the name of the function?
> (I'm just curious...)

There is no function that applications use for this[*].  The interface  
at the Unix layer is opening a special path:

        /.vol/<volume-id>/<file-id>

Where:

        <volume-id> == file system ID as returned in statfs::f_fsid

        <file-id> == file ID as returned in stat::st_ino

This only works on file systems that have persistent file IDs, which  
not all file systems in Mac OS X do.

Prior to Leopard, this was implemented as a file system called volfs.   
Originally, volfs would simply open the file.  Later, it was changed  
to walk up the parent chain, checking the permissions along the way.

In Leopard, volfs was removed and the logic was put into the lookup  
code.  The way it works is the VFS obtains the vnode for the file  
using VFS_VGET(), then builds a full path for the file internally by  
walking up the parent chain (in Mac OS X, file systems that  
participate in volfs-style lookups must be able to return the name and  
parent of a given file).  Once the full path is built up, the file is  
opened up using the path as normal, thereby enforcing the Unix  
permission model.

The semantics are a little weird in the presence of hard links, but  
those are fairly rare in Mac OS X (with the exception of Time Machine  
backup stores).  File systems that support this typically return the  
last name-parent tuple used to look up a file when asked for this  
information.  If the file has not been looked up before, they  
typically report the canonical name-parent tuple; in HFS+, hard links  
have a different CNID that the VFS is aware of, even though the file's  
CNID is the one reported back to userland in stat::st_ino when you  
stat a hard link.  With Xsan, which has UFS hard link semantics, the  
"first" name-parent tuple (the path used to create the file, usually)  
is returned.

[*] There is API for opening a file by its ID ... but I'm not going to  
bother describing the Carbon File Manager here.

Does that answer your question? :-)

-- thorpej