UDFでは、ボリューム識別子、ボリュームセット識別子、論理ボリューム識別子、およびファイルセット識別子の違いは何ですか？

私はそれが見mkudffs四つの異なる識別子のオプションがあります。論理ボリューム（--lvid）、ボリューム（--vid）、ボリュームセット（--vsid）、およびファイルセット識別子を（--fsid）。ただし、それらの意味についてのガイダンスはありません。

それで、UDF仕様に行きました。ISO / IEC 13346別名ECMA-167から始めて、私はそれを見つけます：

10.1.4ボリューム識別子（BP 24）

このフィールドは、ボリュームの識別を指定します。

14.1.10論理ボリューム識別子（BP 112）

このフィールドは、ファイルセットが記録される論理ボリュームの識別を指定します。

14.1.12ファイルセット識別子（BP 304）

このフィールドは、このファイルセット記述子によって記述されるファイルセットの識別を指定しなければならない。

まあ、それは便利でした。

だから、私はOSTA UDF Spec 1.02を試しました。それは私が生成しようとしているUDFバージョンです。それはあまり役に立ちませんでした（ただし、「固定値または些細な値」に対して警告しました）。

UDF 1.50の仕様を試してみました。4.1では、これらの値を表示する前に、4.1.2.1で説明したアルゴリズムを使用したOS固有の変換を適用する必要があることを示しています。もちろん、§4.1の後の次のセクションは§4.2なので、幸運を祈ります。また、LogicalVolumeIdentifierは「ジュークボックス内に複数のメディアが存在する場合の論理ボリューム識別において非常に重要です。名前は通常、ユーザーに表示されるものです」。

だから、私はUDF 2.01仕様を試してみましたが、今では少なくとも4 2 .2.1であることに気付きました。

だから、私が知る限り：

• 論理ボリューム識別子は、ユーザーに表示されるものです（ジュークボックスのみの場合があります）。そのため、ディスクタイトルなど、意味のあるものに設定する必要があります。これは、Windows、Mac OS、またはNautilusが表示するディスクのタイトルだと思います。
• 他のものは、ディスク上のスペースを無駄にするためだけに存在し、目的を実際に説明するものではありません。それにもかかわらず、私はそれらを固定でも些細でもない値に設定すべきです。おそらく、私はそれらをシェークスピアからのランダムな（つまり、固定されていない）行に（つまり、些細ではない）設定する必要があります。

または、さらに良い：他のフィールドは何のためですか？

これらは、LVIDを除く、有用ではない文字列の束です。

フォームmkudffs：

• --lvid論理ボリューム識別子を指定します。指定された文字列を次のフィールドに設定します。
  • 論理ボリューム記述子の論理ボリューム識別子（ECMA-167の図15を参照）
  • 実装での論理ボリューム識別子。（UDF 2.01の 2.2.7.2を参照）
  • ファイルセット記述子の論理ボリューム識別子。（ECMA-167の図9を参照）ファイルセット記述子。（[ECMA-167] [5]の図9を参照）。
    ウィンドウにディスクラベルとして表示される論理ボリューム識別子。
• --vid ボリューム識別子を指定します。指定された文字列を、プライマリボリューム記述子のボリューム識別子フィールドに設定します。（ECMA-167の図6を参照）。最大長は31バイトです。デフォルト値「Linux UDF」。
• --vsidボリュームセット識別子を指定します。指定された文字列を、Primary Volume DesriptorのボリュームセットIDフィールドに設定します。（ECMA-167の図6を参照）。最大長は127バイトです。デフォルト値「Linux UDF」。
  ボリュームセット識別子は、ImgBurn、MagicISOなどの一部のディスク作成プログラムで編集できます。ボリュームがメンバーであるボリュームセットのIDを指定します。
• --fsidファイルセット識別子を指定します。File Set DescriptorのFile Set Identifierフィールドを設定します。（ECMA-167の図9を参照）。最大長は31バイトです。デフォルト値「Linux UDF」。

これらは完全にあなた次第だと思います。エンタープライズプロセスをサポートするためのフィールドがあると思います。簡単に思い浮かぶ1つの用途は、「FOO、2015-12の月次完全バックアップ」などのボリュームセット識別子を使用することです。その場合、ボリューム識別子は「disk 1 of 42」のようなものになります。または、実際にディスクに印刷されたバーコードなどの物理的な識別子があり、ボリューム識別子にそれを保持できます（したがって、ドライブで読み取るか、バーコードリーダーを指すことでディスクを識別できます） ）。

何らかの論理ユニット（「セット」）を形成するファイルシステムにファイルの束を配置するときに、ファイルセット識別子が役立つと思いますが、それらは直感的に「ボリューム」を形成しません。たとえば、「Mariah Carey .gifs 1994-1998」や「Bob's high school essay」などです。

論理的に言えば、これらのフィールドはすべて、標準を開発および/または変更した委員会のメンバーが必要とするデータを含むために存在します。誰かがそれがディスク上のスペースの無駄だと思っているからといって、標準が合意されたとき、その問題に関する意見が一つもなかったことを意味しない。実際、委員会のメンバーの中には、何らかの目的のために彼らが十分に有用であると考えていたので、彼らが規格に組み込まれました。標準で明示的に定義されていないものはすべて解釈が可能であるため、任意の目的に使用できるか、標準で明示的に定義されるまで安全に無視できます。ソフトウェアオーサリングの観点から、「mkudffs」はこれらのフィールドを何に使用すべきかを定義する必要はありませんが、

これらの価値観は他の仕様に向けられていると思います。私の例ではLinuxを参照しますが、これはWindowsには適用されないという意味ではありません。それらの仕様。そこに隠れているだけです。

Linuxで次のcmdを実行し、出力を確認します：blkid

/ dev / x：LABEL = "Windows" UUID = "？" TYPE = "ntfs" PARTLABEL = "基本データパーティション" PARTUUID = "？"

/ dev / y：LABEL = "Linux" UUID = "？" TYPE = "ext4" PARTLABEL = "storage" PARTUUID = "？"

ご覧のとおり、すべてに2つの説明フィールドがあります。

• パーティション
• そのパーティション上のファイルシステム

どちらの場合でも、最初は人間が読める記述であり、後者はマシンの記述です。ドメインネームシステム（DNS）と同様に、マシンの説明（UUID）は一意である必要があるためです。したがって、パーティション用のnx 2 x 2データフィールドについて説明できます。ただし、光メディアはパーティション分割されないため、未加工メディアはパーティション自体としてカウントされます。つまり、常に2 x 2 = 4個の属性があります。上記の例にUDFプロパティを適合させてみましょう。

/ dev / x：LABEL = "LVID" UUID = "VID" TYPE = "UDF" PARTLABEL = "VSID" PARTUUID = "FSID"

何時間も検索して多くの記事を読みましたが、これを確認できませんでした。したがって、これは単なる仮定です。しかし、LVIDの場合は、用語の定義と試行によって保証されます。LinuxおよびWindows（後者はWinCDemuを使用）は、このプロパティをパーティションのラベルとして使用します。これは、光メディアの場合、メディア自体です。

実際にはかなりきちんと収まりますが、1つの疑問が生じます。追加のUUIDプロパティがあり、これは何らかの実装エラーであると信じがちです。私は一度このネットワークで読んだことがあるので、これは後で実装されたということです。UUIDでUDFメディアをマウントできませんでした。そのため、特定のプロパティフィールドの誤解である可能性があります。現在のUUIDがどこに配置されているかわかりませんが、blkidはこれをUUIDとして読み取ります。これがUDFドライバーまたはblkidの問題かどうかはわかりません。誰かが、対応する個人/グループへのヒントとともにメールを書いているかもしれません。