Re: mkisofs -M makes no attempt to reconstruct multi-extent files
>>> You used mkisofs incorrectly
>> Command line sequence was *tailored* to allow to produce usable input
>> for *hex editor* in less than minute.
>
> Why did you use -C16,xxx?
>
> This is definitely wrong.
Why I even bothered to report this? To be told that I can't use
multi-sessioning options to dump second session data to separate file in
order to examine its directory table in hex editor?
>>> and you seem to missinterpret the results
>>> from the tool you used to list ISO-9660 directories.
>> What is it you doubt? a) My lay-out of directory records? b)
>> Interpretation of what they represent? c) "Would be correct" lay-out?
>>
>> If a), then you either didn't bother to examine them close enough or
>> misinterpreted them.
>>
>> If b), then consider following output from Windows XP dir command for
>> actual two-session recording:
>
> I am sure that you did not missinterpret the results in case you used isoinfo.
I used hex editor, yet I can assure that despite this I did not
misinterpret the results.
> I explained you that the problem is the incorrect allocation os _new_ space for
> the old file.
Well, why don't you back up your explanation with some evidence? I've
provided directory records' layout, even XP dir output for actual
multi-session recording, while you only said what you *would* use to
examine single-session recording...
BUT NEVER MIND!!! I'm going to throw in some more information supporting
my claim and then I'm going to *stop* following this thread, because I
simply don't have time or energy arguing.
Exhibit #1. 'isodump -i 1st.iso' output:
34 [ 1] 17 2048 02/*.
34 [ 1] 17 2048 02/*..
40 [ 1] 18 -2048 80/ 5G.0;1
40 [ 1] 200017 1073743872 00/ 5G.0;1
Exhibit #2. 'isoinfo -l -i 1st.iso' output:
Directory listing of /
d--------- 0 0 0 2048 May 20 2008 [ 23 02] .
d--------- 0 0 0 2048 May 20 2008 [ 23 02] ..
---------- 0 0 0 5368709120 May 20 2008 [ 24 80] 5G.0;1
Exhibit #3. 'isodump -i /dev/dvd' output for two-session recording with
5G.0 in first session and 5G.1 in second:
34 [ 1] 2800c7 2048 02/*.
34 [ 1] 2800c7 2048 02/*..
40 [ 1] 18 -2048 80/ 5G.0;1
40 [ 1] 2800c8 -2048 80/ 5G.1;1
40 [ 1] 4800c7 1073743872 00/ 5G.1;1
42 [ 1] 200017 1073743872 00/ 5G000.0;1
Note starting extent addresses for 5G.0 and 5G000.0. They are the *same*
as for 5G.0 extents in 1st.iso. These are original extents and no "new
block addresses were assigned to old files." Also note that it's exactly
same directory records layout depicted in my original report. Oh!
isodump was modified to seek to second session, I simply hard-coded
offset for this particular recording.
Exhibit #4. 'isoinfo -l -T xxxx -i /dev/dvd' output for same recording:
Directory listing of /
d--------- 0 0 0 2048 May 20 2008 [2621639 02] .
d--------- 0 0 0 2048 May 20 2008 [2621639 02] ..
---------- 0 0 0 9663674368 May 20 2008 [ 24 80] 5G.1;1
---------- 0 0 0 1073743872 May 20 2008 [2097175 00] 5G000.0;1
Exhibit #5. Attached mkisofs/multi.c patch. Note that I make no claims
that it's complete solution for the problem. On the contrary, I can
confirm that the patched mkisofs for example fails to handle situation
when 5G.0 shrinks to less than 4GB in second session. The sole purpose
of the patch is to provide support for original claim [summarized in
subject]. All the patch does is reconstruct mxpart member of
directory_entry structure for extents in previous session.
Exhibit #6. 'isodump -i /dev/dvd' output for two-session recording
performed with patched mkisofs.
34 [ 1] 2800c7 2048 02/*.
34 [ 1] 2800c7 2048 02/*..
40 [ 1] 18 -2048 80/ 5G.0;1
40 [ 1] 200017 1073743872 00/ 5G.0;1
40 [ 1] 2800c8 -2048 80/ 5G.1;1
40 [ 1] 4800c7 1073743872 00/ 5G.1;1
Exhibit #7. 'isoinfo -l -T xxxx -i /dev/dvd' output for same recording:
Directory listing of /
d--------- 0 0 0 2048 May 20 2008 [2621639 02] .
d--------- 0 0 0 2048 May 20 2008 [2621639 02] ..
---------- 0 0 0 5368709120 May 20 2008 [ 24 80] 5G.0;1
---------- 0 0 0 5368709120 May 20 2008 [2621640 80] 5G.1;1
I can even confirm that it works as it should in XP. A.
--- ./mkisofs/multi.c.orig 2007-08-20 18:17:17.000000000 +0200
+++ ./mkisofs/multi.c 2008-05-20 19:20:53.000000000 +0200
@@ -538,6 +538,7 @@
unsigned char *tt_buf;
UInt32_t tt_extent;
UInt32_t tt_size;
+ int mxpart;
static int warning_given = 0;
@@ -589,6 +590,7 @@
tt_extent = 0;
seen_rockridge = 0;
tt_size = 0;
+ mxpart = 0;
while (i < len) {
idr = (struct iso_directory_record *) & dirbuff[i];
if ((i + (idr->length[0] & 0xFF)) > len) {
@@ -635,6 +637,20 @@
(*pnt)->rr_attr_size = 0;
(*pnt)->total_rr_attr_size = 0;
(*pnt)->de_flags = SAFE_TO_REUSE_TABLE_ENTRY;
+
+ /*
+ * Track multi-extent files.
+ */
+ if (idr->flags[0]&ISO_MULTIEXTENT) {
+ (*pnt)->de_flags |= MULTI_EXTENT;
+ (*pnt)->mxpart = ++mxpart;
+ }
+ else if (mxpart) {
+ (*pnt)->de_flags |= MULTI_EXTENT;
+ (*pnt)->mxpart = ++mxpart;
+ mxpart = 0;
+ }
+
#ifdef APPLE_HYB
(*pnt)->assoc = NULL;
(*pnt)->hfs_ent = NULL;
Reply to: