https://bugs.kde.org/show_bug.cgi?id=367639
--- Comment #33 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> If ScsiCommand 0x52 (MMC_READ_TRACK_INFORMATION) 0x1(incomplete) wrongly
> return 0 (as mnl experienced),
The answer 0 is correct. It is just given by the wrong entity,
namely the drive and not the filesystem superblock.
A MMC drive regards an overwritable medium as having a single session
with a single track.
This track is readable beginning at block 0. Thus the first -C value is
determined by the drive as 0.
The track is also writable beginning at block 0. Thus the second -C
value is determined by the drive as 0.
But we do not want to overwrite the existing ISO. We want to append
in multi-session style.
This is the reason why growisofs began to exist. Andy Polyakov wanted
multi-session on media which are not prepared for multi-session but
rather allow random access writing.
man growisofs begins by:
growisofs was originally designed as a frontend to genisoimage to
facilitate appending of data to ISO9660 volumes residing on random-
access media such as DVD+RW, DVD-RAM, plain files, hard disk parti‐
tions. In the course of development general purpose DVD recording sup‐
port was implemented, and as of now growisofs supports not only random-
access media, but even mastering of multisession DVD media such as
DVD+R and DVD-R/-RW.
It was Andy's great invention to inquire the ISO 9660 superblock and to
use a block number after the end of the ISO as pseudo Next Writable Address.
Currently K3B is prepared only for "multisession DVD media" but not for
the "random-access media" which growisofs originally targets.
This is because it does not use growisofs to start mkisofs but rather starts
both program side by side.
> then how to fix it?
Do it like Andy (and me in xorriso):
- Inquire the ISO filesystem size.
- Choose a block address after the end of the ISO.
- Instruct all involved programs that this address will be used for
writing the add-on session.
growisofs does the ISO inquiry by the call
from_733(descr->volume_space_size);
"733" refers to ECMA-119 paragraph 7.3.3 which says:
7.3.3 Both-byte orders
A numerical value represented by the hexadecimal representation
(st uv wx yz) shall be recorded in an eight-byte field as
(yz wx uv st st uv wx yz).
For example, the decimal number 305419896 has (12 34 56 78) as its
hexadecimal representation and is recorded as (78 56 34 12 12 34 56 78).
"descr" is the content of the Primary Volume Descriptor (ECMA-119, 8.4).
This is recorded at block 16.
"->volume_space_size" accesses the bytes at offset 80 in the Descriptor.
ECMA-119, 8.4.8:
Volume Space Size (BP 81 to 88)
This field shall specify as a 32-bit number the number of Logical Blocks
in which the Volume Space of the volume is recorded.
This field shall be recorded according to 7.3.3.
Note that ECMA-119 counts byte position BP beginning with 1. I.e. BP 81
is byte offset 80.
So at byte offset 80 in block 16 begins the little-endian 4-byte block
count of the ISO. At offset 84 begins the same number represented as
big-endian.
In growisofs.c this is expressed by a C structure:
struct iso_primary_descriptor {
... members with together 80 bytes ...
unsigned char volume_space_size [8];
...
};
But one may simply do fseek() to 32768+80, read the 4 bytes, and interpret
them as little-endian 32 bit value.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
