Re: [Libcdio-devel] libcdio treats a >4GB ISO-9660 file as 2 separate parts

[Thomas Schmitt]

Hi,

i looked into Linux and libisofs for their methods of handling level 3:

Linux in fs/isofs/inode.c records with the inode a struct iso_inode_info
(see fs/isofs/inode.h) which knows the byte address of the second directory
record of the file
        unsigned long i_next_section_block;
        unsigned long i_next_section_offset;
Content reading is done by isofs_get_blocks(). When the first section is
exhausted, it switches to the data blocks governed by the second directory
record. If this has the multi-extent flag bit set, then the byte address
of the third directory record is memorized for the next switching. And so
on up to 100 records.
This implies that reading a high block causes several readings of directory
records before content data can be read.
When the VFS inode is created, function isofs_read_level3_size() hops
along the chain of directory records of the file and accumulates the size.

My predecessor in libisofs implemented an array of struct iso_file_section
which records block addresses and byte counts. It is attached to IsoFileSource
which is attached to IsoFile, which is one of the personae of IsoNode.
Similar to Linux, the medium block address of a file block is determined by
hopping along the chain of sections until enough blocks are skipped.
Other than with Linux, there is no need to read directory records from
the medium while addressing or reading data blocks from a file.

Both implementations are prepared for File Sections which are not seamless
neighbors in the data blocks area. So the idea to rely on such a seamless
and well sorted block range seems risky.
I did not really check whether the implementations support unaligned File
Section ends with the sections before the last one.


Have a nice day :)

Thomas