Q：Carbon アプリケーションに対して fs_usage を実行したとき、/.vol ディレクトリ内の項目へ多数のアクセスがあります。このディレクトリは何ですか？ なぜアクセスしているのでしょうか？

A：このディレクトリは、volfs ファイルシステムのマウントポイントとして使われています。volfs ファイルシステムは、BSD ファイルシステム上で Carbon File Manager API をサポートするための核となる要素です。歴史的には、 BSD システムでは、POSIX 形式のパスによるファイルまたはディレクトリへのアクセスだけが許されます。しかし、 Carbon File Manager API では、カタログノード ID（CNID、ファイル ID 参照またはディレクトリ ID）による項目へのアクセスも許されます。 volfs は、2 つのモデルの橋渡しをし、BSD ファイルシステム上で Carbon File Manager API が機能するようにします。

Carbon による volfs ファイルシステムの使用方法は次のとおりです。

• <vRefNum>、<dirID>、および <name> の 3 つタプル（多くの場合 FSSpec にバンドルされています）を使って項目にアクセスする場合、Carbon File Manager は、次の形式のパスを形成します。
  

  /.vol/<volumeID>/<dirID>/<name>

  ここで、
  • <volumeID> は、32 ビットの volfs ボリューム識別子（Carbon は、ボリュームの vRefNum をこの値に対応させる内部テーブルを維持しています）を 10 進数で表したものです。
  • <dirID> は、ディレクトリ ID を 10 進数で表したものです。
  • <name> は、項目名を UTF-8 で表したものです。
• <vRefNum> と <CNID> のペアを使って項目にアクセスする場合、Carbon File Manager は次の形式のパスを形成します｡
  

  /.vol/<volumeID>/<CNID>

  ここで、
  • <volumeID> は上記と同様、32 ビットの volfs ボリューム識別子を 10 進数で表したものです。
  • <CNID> は、カタログノード ID を 10 進数で表したものです。
• FSRef を使って項目にアクセスする場合、Carbon File Manager は、FSRef にあるプライベートな情報に基づいて、volfs パスを形成します。

上記のパスを形成したら、Carbon File Manager は、そのパスを使って項目に直接アクセスでき、項目への POSIX パスを作成する必要がありません。これにより、時間が節約でき（POSIX パス作成のコストは高い）、完全パスが変更されていても項目にアクセスすることができます。たとえば、ファイルのエイリアスを作成すれば、Alias Manager は、エイリアス内にファイル ID の参照を格納します。以後、このエイリアスを解決するとき、Alias Manager は volfs を使ってこのファイルにアクセスします。これにより、ファイル名や POSIX パスが変わっていたとしてもエイリアスは解決されます。

すべてのファイルシステムで volfs がサポートされているわけではありません。Mac OS X 10.1 以降では、次のファイルシステムで volfs がサポートされています。

• HFS Plus
• HFS
• AppleShare
• ISO-9660
• UDF

次のファイルシステムでは volfs がサポートされていません。

• UFS
• NFS
• DOS/FAT
• CDDA
• SMB
• WebDAV

このリストの内容は今後、変わる可能性があります。

ファイルシステムで volfs がサポートされていない場合、Carbon File Manager は、ほかの方法を使って、そのファイルシステム上のカタログノード ID に相当するものを形成します。通常は、これらの方法では、永続的な CNID は提供されません。たとえば、UFS ファイルシステム上で Finder を使ってファイルのエイリアスを作成し、その後ファイルを別のフォルダに移した場合、エイリアスは解決されません。

VFS プラグインファイルシステムを記述する場合、volfs をサポートするかどうかを選択できます。volfs をサポートする場合は、行わなければならないことがいくつかあります。

1. mount 構造体の mnt_flag フィールドに MNT_DOVOLFS フラグをセットしなければなりません。
2. vfsops で、getattrlist、setattrlist、および exchange の処理をサポートしなければなりません。
3. lookup と cachedlookup のエントリポイントにおいて、名前付きフォークを照会する機能をサポートしなければなりません。
4. vfsops に、vget の処理を実装しなければなりません。具体的には、vfsops 構造体の vfs_vget フィールドを、CNID を vnode に対応付けることができるルーチンに 設定しなければなりません。
5. getattr vnodeop エントリポイントにある vattr 構造体の va_fileid フィールドに CNID を返さなければなりません。 CNID 情報は、以降改めてボリュームをマウントしたときも継続して維持できなければなりません。できない場合には、volfs をサポートするべきではなく、その代わり、 Carbon File Manager を使って CNID をエミュレートします。
6. getattrlist vnodeop エントリポイントでは、fid_objno フィールドに CNID を設定することによって、ATTR_CMN_OBJID 属性と ATTR_CMN_OBJPERMANENTID 属性の取得要求に応えなければなりません。

Darwin のオープンソースプロジェクトにある次の volfs_vnops.c ファイルの解説を読めば、volfs の実装の詳細について知ることができます（このリンク先を見るにはアカウントが必要です。アカウントは Apple Public Source License に同意することによって作成できます）。

[2002 年 2 月 14 日]