したがって、これは少し具体的すぎて、誰もが読むことができず、誰もが助けることができないかもしれません. でも、もしかしたらこれをやったことがある人もいるかもしれません。
私は現在、信頼できるがあまり正確ではない libdvdread ライブラリを使用して、ISO ファイル/デバイスを読み取ります。ただし、この場合、特定の実装はそれほど重要ではありません。UDF ファイル システムの読み取り方法について詳しく説明しています。私は Ecma-167 と udf260 の両方の PDF ファイルをたくさん読みました。
まず、市販のブルーレイからコピーされた画像と同じように動作しているように見える IMGBURN の ISO イメージを見てみましょう。
ブロックは次のように配置されます。
Block 32 TagID: 1 TAGID_PRI_VOL
Block 33 TagID: 4 TAGID_IMP_VOL
Block 34 TagID: 5 TAGID_PARTITION
Block 35 TagID: 6 TAGID_LOGVOL
Block 36 TagID: 7 TAGID_UNALLOC_SPACE
Block 37 TagID: 8 TAGID_TERM
Block 64 TagID: 9 TAGID_LOGVOL_INTEGRITY
Block 65 TagID: 8 TAGID_TERM
Block 256 TagID: 2 TAGID_ANCHOR
Block 288 TagID: 266 TAGID_EXTFENTRY
Block 320 TagID: 256 TAGID_FSD
Block 321 TagID: 8 TAGID_TERM
Block 322 TagID: 266 TAGID_EXTFENTRY
Block 323 TagID: 257 TAGID_FID
Block 324 TagID: 266 TAGID_EXTFENTRY
Block 325 TagID: 266 TAGID_EXTFENTRY
Block 326 TagID: 257 TAGID_FID
Block 327 TagID: 266 TAGID_EXTFENTRY
そこで、ISO イメージの読み取りを開始します。
* Read Block 256 which is 2 TAGID_ANCHOR
* Read Block 32 which is 1 TAGID_PRI_VOL
* Read Block 33 which is 4 TAGID_IMP_VOL
* Read Block 34 which is 5 TAGID_PARTITION
Partiton: number 0, start 288, length 2291200, AccessType 1
* Read Block 35 which is 6 TAGID_LOGVOL
LogVolume 2048:70:2
Volume 0 type 01 (len 6) Seq 0001 Part 0000
Volume 1 type 02:
Partition identifier: '*UDF Metadata Partition'
Metadata Partition MainLoc 00000000, MirrorLoc 0022F5A9, BitmapLoc FFFFFFFF, AllocSize 00000020, AlignSize 0020, Flags 1.
returning Start 288
Found partition at 288 length 2291200
Starting scan from 288 (metadata adjusted)
ここまでは順調ですね。この例では 0 の「メタデータのメイン ファイルの場所」を取得し、それをパーティションの先頭に追加して、FSD を探します。これは、「メタデータのメイン ファイルの場所」が 0 ではない例でも機能するようです。これについては後で詳しく説明します。
FSD を検索すると、最初に見つかった項目は次のとおりです。
* Read Block 288 which is 266 TAGID_EXTFENTRY
TagID 266 with filetype 250
Metadata Main at location 32 (+partition.start 320)
Ecma-167 は filetype=250 を定義し、「メタデータ メイン ファイル」を持ち、AD.Location はメタデータを指します。filetype=251 (メタデータ ミラー ファイル) を見つけることも可能です。
「メタデータのメイン ファイル」の場所 (ここでは 32) を、FSD を「実際に」探す場所への間接的なポインターとして使用します。何らかの理由で、これは partition.Start + Location (288 + 32) = 320 です。
ブロック 320 で、FSD を見つけます。だから多分私は正しい軌道に乗っています。
Now Scanning from 320
* Read Block 320 which is 256 TAGID_FSD
RootICB at 2 length 2048
MapICB starting at 320,2 -> 322
FSD を読み取りました。RootICB は「+2」です。これが "partition.Start + 2" (288+2) であると予想していましたが、これは機能しません。機能するのは "FSD_Location + 2" (320+2) です。これは本当にそうでしょうか？
DVD ISO では、FSD_Location=0 (途中で EXTFileInfo+250 がないため、パーティションの最初のブロック) であるため、このロジックを使用しても機能します。
それが正しいと仮定しましょう。
* Read Block 322 which is 266 TAGID_EXTFENTRY
libdvdread: reading AD chain 0
UDFMapICB TagID 266 ExtFile with filetype 4
Part.Start 288 FSD loc 320 RootICB 2 (len 2048) File has loc 3
したがって、322 のブロックは実際には、filetype==4 (ディレクトリ) の ExtFileInfo であり、location = +3 にあります。繰り返しますが、これは "fsd_location + 3" = 323 のようです。
Found '/' at 323 (size 152).
* Read Block 323 which is 257 TAGID_FID
DVDReadDir(.)
DVDReadDir(BDMV)
etc
成功。すべての内容をリストに載せます。
ここで私は混乱します。OSX の「newfs_udf」を使用して UDF テスト イメージを作成します。
# mkfile 1G roger.iso
# newfs_udf -eu -r 2.60 -v HIGHLANDER roger.iso
# hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount roger.iso
# hdiutil mount -nobrowse roger.iso
# mkdir /Volumes/HIGHLANDER/A.DIRECTORY.ENTRY
ブロックは次のとおりです。
Block 20 TagID: 1 TAGID_PRI_VOL
Block 21 TagID: 4 TAGID_IMP_VOL
Block 22 TagID: 5 TAGID_PARTITION
Block 23 TagID: 6 TAGID_LOGVOL
Block 24 TagID: 7 TAGID_UNALLOC_SPACE
Block 25 TagID: 8 TAGID_TERM
Block 36 TagID: 9 TAGID_LOGVOL_INTEGRITY
Block 37 TagID: 8 TAGID_TERM
Block 256 TagID: 2 TAGID_ANCHOR
Block 257 TagID: 264 TAGID_SPACE_BITMAP
Block 289 TagID: 266 TAGID_EXTFENTRY
Block 290 TagID: 266 TAGID_EXTFENTRY
Block 291 TagID: 256 TAGID_FSD
Block 292 TagID: 266 TAGID_EXTFENTRY
Block 293 TagID: 266 TAGID_EXTFENTRY
Block 294 TagID: 266 TAGID_EXTFENTRY
Block 295 TagID: 266 TAGID_EXTFENTRY
Block 296 TagID: 266 TAGID_EXTFENTRY
Block 323 TagID: 264 TAGID_SPACE_BITMAP
Block 449 TagID: 259 TAGID_INDIRECTENTRY
この ISO を読むことも、少なくとも最初はうまくいきます。
* Read Block 256 which is 2 TAGID_ANCHOR
* Read Block 20 which is 1 TAGID_PRI_VOL
* Read Block 21 which is 4 TAGID_IMP_VOL
* Read Block 22 which is 5 TAGID_PARTITION
Partiton: number 0, start 257, length 523774, AccessType 4
* Read Block 23 which is 6 TAGID_LOGVOL
LogVolume 2048:70:2
Volume 0 type 01 (len 6) Seq 0001 Part 0000
Volume 1 type 02:
Partition identifier: '*UDF Metadata Partition'
Metadata Partition MainLoc 00000020, MirrorLoc 0007FDFD, BitmapLoc 00000021, AllocSize 00000020, AlignSize 0001, Flags 0.
returning Start 257
Found partition at 257 length 523774
Starting scan from 289 (metadata adjusted)
* Read Block 289 which is 266 TAGID_EXTFENTRY
TagID 266 with filetype 250
Metadata Main at location 34 (+partition.start 291)
* Read Block 291 which is 256 TAGID_FSD
RootICB at 1 length 2048
* Read Block 292 which is 266 TAGID_EXTFENTRY
UDFMapICB TagID 266 ExtFile with filetype 4
Part.Start 257 FSD loc 291 RootICB 1 (len 2048) File has loc 34
ここでは、ExtFileInfo+Filetype=250 が正しく検出されたことを追加することで、メタデータ パーティションが +32 になっていることに注意してください。これは +34 であり、FSD が正しく取得されます。
FSD の RootICB は FSD から +34 で、これは 291+34 = 325 です。
そして、それは失われます。私はそれが292であるべきだと思いますが、;
...ブロック リストに、FID がまったくないことがわかります。この ISO イメージの 16 進ダンプを見ると、「A.DIRECTORY.ENTRY」がブロック 292 で見つかります。これは ExtFileEntry です。metadata-main-file-location を探して私たちを送り出したまさにその 1 つです。
ExtFileInfo には、ICB がそのデータを指すファイル記述子が 1 つしか含まれていないと思いました。それでも、オフセット +380 程度のこのブロック内には、ルート (null)、「A.DIRECTORY.ENTRY」、および「.Trashes」があります。
私の質問は、OSX が FID をどうにかして ExtFileEntry に圧縮するかということだと思います。FIDブロックなしで行きます。これは「有効」ですか？この状況を検出するにはどうすればよいですか? この ExtFileInfo には、「場所をたどって FID を探すのではなく」、「このブロックを解析してエントリを増やす」必要があることを示す何かがありますか。
ICB を計算するとき、ディレクトリには "fsd_location + icb.location" を使用する必要がありますが、ファイル (実際のファイル データを読み取るため) では "partition.Start + icb.location" を使用する必要があります。これは期待どおりに機能します (ディレクトリ リストとファイルに違いはありません) が、正しくないようです。
あなたがそれをすべて読んだなら、あなたは素晴らしいです:)さて、私にいくつかの手がかりを与えることができれば...