[Debburn-devel] CD-Extra issues
Ralf Baechle
ralf at linux-mips.org
Fri Dec 5 11:52:04 UTC 2014
On Thu, Dec 04, 2014 at 11:49:40AM +0100, Thomas Schmitt wrote:
> > [od] -t x1 gives a bytewise hexdump:
>
> This must have been invented after i read S.R.Bourne's
> The Unix System. :))
:-)
And remember this is not UNIX but GNU-Linux ;-)
> > 0000000 37 76 9a 9e 71 34 3e 02 39 22 19 83 76 b9 2d 94
> > 0000020 8c d7 86 36 ad f8 7f b6 e5 62 bf bd 94 82 94 fa
> > 0000040 63 f8 f2 6d aa ce ed 52 59 3a fb 83 c4 18 e6 5f
>
> This surely does not contain the start of a plausible
> directory record. There must be a 32-bit block address in it,
> in the range of the size of a CD. Thus it must contain at
> least one zero byte.
>
>
> > cd/track-01.mp3
> > 049000 37 76 9a 9e 71 34 3e 02 39 22 19 83 76 b9 2d 94
>
> So how did the interpretation of the tree of directory
> records get into the data content of a payload file ?
> (Or is my theory about the inode numbers wrong, and we
> are looking at the wrong block ?)
>
>
> I understand your directory structure is simply
> cd/
> track-01.mp3
> ... only data tracks, no directories ...
Correct.
> Possibilities which come to me:
> - The root directory record could point to the wrong block
> as start of its directory record list.
> - The directory record of /cd could point to the wrong block
> as start of its directory record list.
> - The directory directory record list of / could contain garbage.
> - A directory record of a data file in /cd could falsely be
> marked as directory pointing to a list of directory records.
>
> Interpretation begins at the Primary Volume Descriptor (PVD)
> at block number image_start + 16 = 291130. ECMA-119, 8.4.
> It should begin by the magic "\001CD001":
> 01 43 44 30 30 31
> At byte offset 0234 starts the Directory Record for the root
> directory (i.e. the root inode).
I did some deeper analysis yesterday before received this your last
email. I found the struct iso_primary_descriptor on the volume at
offset 0x8000:
008000 01 43 44 30 30 31 01 00 4c 49 4e 55 58 20 20 20
soh C D 0 0 1 soh nul L I N U X sp sp sp
[...]
This is the PD:
008090 00 00 00 00 00 04 71 d6 00 00 00 00 22 00 dc 71
0080a0 04 00 00 04 71 dc 00 10 00 00 00 00 10 00 46 01
0080b0 01 01 00 00 04 02 00 00 01 00 00 01 01 00 20 20
0080c0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
struct iso_directory_record {
char length [ISODCL (1, 1)]; 22
char ext_attr_length [ISODCL (2, 2)]; 00
char extent [ISODCL (3, 10)]; dc 71 04 00 00 04 71 dc
char size [ISODCL (11, 18)]; 00 10 00 00 00 00 10 00
char date [ISODCL (19, 25)]; 46 01 01 01 00 00 04
char flags [ISODCL (26, 26)]; 02
char file_unit_size [ISODCL (27, 27)]; 00
char interleave [ISODCL (28, 28)]; 00
char volume_sequence_number [ISODCL (29, 32)]; 01 00 00 01
unsigned char name_len [ISODCL (33, 33)]; 01
char name [0]; 00
} __attribute__((packed));
Little and big endian - proper committee code ;-)
When mounting I get:
[266750.654657] ISOFS: Interleaved files not (yet) supported.
[266750.654666] ISOFS: File unit size != 0 for ISO file (18642688).
[266750.654673] ISOFS: changing to secondary root
[266750.657264] ISOFS: Interleaved files not (yet) supported.
[266750.657270] ISOFS: File unit size != 0 for ISO file (18642816).
[266750.657275] isofs_fill_super: root inode is not a directory. Corrupted media?
$ printf "%x\n" $((18642688 * 32 / 2048))
471dc
$ printf "%x\n" $((18642816 * 32 / 2048))
471de
And 0x471dc is the bogus extend from above iso_directory_record.
Something in my analysis is not quite right though. I've manually
decoded interleave as 0 but the "Interleaved files not (yet) supported."
message is printed only for non-zero values. Probably its generated
further down the road for another inode than the root directory.
The first block of the 2nd session is 291114 / 0x4712a, that is the root dir
is located at offset 0x471dc - 0x4712a = 0xb2. But for an fs built with
-C 0,0 (or without -C) the root dir is stored at 0x1c. That's a difference
of 0x96 which is 150. And 150 is the first argument to mkisofs -C 150,291114.
I'm just learning ISO9660 by doing but this appears wrong, shouldn't have been
added. Now both wodim -msinfo and cdrdao msinfo print that 150 because there's
a pregap also before the 1st audio track on this CD. I've now changed the
audio tracks such that there is no pregap before the first track:
track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 0 mode: -1
track: 2 lba: 23904 ( 95616) 05:20:54 adr: 1 control: 0 mode: -1
[...]
track: 17 lba: 270073 ( 1080292) 60:02:73 adr: 1 control: 0 mode: -1
track:lout lba: 279564 ( 1118256) 62:09:39 adr: 1 control: 0 mode: -1
Next funnyness, after burning the soundtrack with a the pregap only for
track 2 and up I get:
$ cdrdao msinfo
[...]
0,291114
[...]
$ wodim -msinfo
0,290964
Not sure which one to believe - but I use wodim's 0,290964:
$ mkisofs -o cd/mp3.iso -C 0,290964 -r -J cd/*.mp3
$ wodim cd/mp3.iso
Another check of the TOC shows that track 18 now indeed is starting at 290964,
so 0,290964 seems to be right. The root directory record of an ISO fs
built with -C 0,0 is at 0x1c. I'd expect everything to shift by 290964 /
0x47094 blocks for -C 0,290964. That would be a block number of 0x470b0
which indeed is what I'm seeing in the image with -C 0,290964.
> Directory records form the tree of directories and files.
> Their format is defined in ECMA-119, 9.1.
> A directory record begins by a byte which tells its length,
> thus pointing to its successor in the list.
> The list ends at the byte given by the Data Length of their
> parenrtd directory record.
>
> Directories are marked by bit 1 in the File Flags byte.
> ECMA-119, 9.1.6.
> So only the root record and the record of "cd" should have
> this bit set.
Set in above manually decoded record so good that far.
> I would be interested in seeing blocks 291114 to 291292 of
> the image. If this is possible then please send them to me
> by private mail as gzipped binary data.
I think I untangled the mystery so no more need to send the data. But if
you're still interested in the data I can send it to you. And the blame
is on mkisofs.
Thanks!
Ralf
More information about the Debburn-devel
mailing list