[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-xorriso] ISO-Disc not recognized

From: Thomas Schmitt
Subject: Re: [Bug-xorriso] ISO-Disc not recognized
Date: Thu, 04 Jun 2015 12:54:34 +0200


> >    dd if=/dev/zero bs=32k count=250 | \
> >      xorriso -as cdrecord -v dev=/dev/thedvdwriter stream_recording=on -
> This works fine!

So it is probably one of the first UDF Anchors.
There are several of them spread over an UDF filesystem.

ECMA-167 (the fat'n'hairy momma of UDF) says:
" Anchor points
Let k be ip(n/59), where n is the largest logical sector number
in the volume space. Anchor points shall be at two or more of
the following logical sector numbers: 256, n-256, n and all
the nonzero integral multiples of k not greater than n."
"6.5 Arithmetic notation
The notation ip(x) shall mean the integer part of x."

So i understand it sprays about 60 superblocks over the
UDF filesystem.

If the newly written ISO is small enough to let the first anchor
at block 256 survive, then it might be seen by a stupid mount
software, which does mistake it for a part of an ISO-UDF hybrid.
(Unplausible, of course, because the anchor is outside the ISO.) 

> Is there a header, magic bytes,... to search for?

ECMA-167, 3 / 7.2 "Descriptor tag" specifies 16 bytes.
The first two bytes should say 2 as little endian word.
The next two bytes are 2 or 3, depending on version.
A single byte "checksum" tells the sum of bytes 0-3,5-15
modulo 256. There's more info, including a 16 bit CRC
of bytes following the tag. (ECMA-167 is available for free.)

> Without the "count=..." dd writes automatically till the end. So the part
> where you identify the number of blocks is non-essential. ;)

But that would not be scientific !


Whatever. Mistaking trailing garbage as a filesystem and
then failing to mount is a shortcomming of the mounter,
not of the burn program.
The superblock (aka "Primary Volume Descriptor) of ISO 9660
clearly tells where the filesystem ends and garbage begins.

Said this, i would try to work around by zeroizing up to
block 256 (i.e. byte 524288), in order to kill the first
UDF anchor point.
This might suffice to put the mounter back on the rails.

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]