tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: inode open




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



Home | Main Index | Thread Index | Old Index