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.
The reason is in the beginning of merge_isofs() in multi.c. In
particular for (i=0;i100;i++) loop. As area prior sector 16 is allowed
to be and customarily used for other purposes (such as hybrid disks),
there is no guarantee that data there does not resemble iso9660 volume
descriptor. I don't want mkisofs to look at sectors prior 16th at all,
but start directly with volume descriptor. One can argue that mkisofs
should have seek-ed to 16th sector all by itself, but the code has been
around for so long, that it should be considered feature, not bug.
In theory, I could change mkisofs to start looking at sector #16
Once again, the code has been around for so long, that it should be
considered to be a feature, and therefore no modifications should me
made. In other words, don't.
But if you put something that looks like a PVD between sector #0 and
sector #15, then your software is wrong anyway. Are you really doing this?
I'm not putting anything between sectors #0 and #15, but it does not
mean that some other program does not. And by doing so such program does
*not* violate any standards, moreover, it's common practice. mkisofs
itself puts data there if instructed to generate hybrid disk. Data put
by mkisofs does not normally resemble PVD, but *formally* there is no
guarantee that it won't. Therefore it's not inappropriate (or in other
words it's not definitely wrong) to guide mkisofs directly to 16th sector.
Your claim that the file is non-contiguous is just wrong.
Having 9GB 5G.0 file in XP (previously discussed), if I read byte prior
4GB-2KB offset in the file, I get last byte from LBA X+0x20-2, and
when I read next byte, i.e. at 4GB-2KB offset in file I get data from
LBA Y, and there is 1GB gap between X+0x20 and Y.
I cannot speak for the sofware you used to look at the image.
In other words you're implying that under no circumstances results
obtained with software of my choice could be possibly right.
I looked at my test results using isoinfo and isoinfo did not show
non-contiguous files.
Already mentioned 'isoinfo -l -i /dev/dvd' output:
Directory listing of /
d- 000 2048 May 20 2008 [2621639 02] .
d- 000 2048 May 20 2008 [2621639 02] ..
-- 000 9663674368 May 20 2008 [ 24 80] 5G.1;1
-- 000 1073743872 May 20 2008 [2097175 00] 5G000.0;1
In other words, like Windows XP kernel, isoinfo also reckoned that there
are one ~9GB and one ~1GB file. Now suggested 'isoinfo -debug -l -i
/dev/dvd' output:
Directory listing of /
d- 000 2048 May 20 2008 [2621639 02] .
d- 000 2048 May 20 2008 [2621639 02] ..
-- 000 4294965248 May 20 2008 [ 24 80] 5G.0;1
-- 000 4294965248 May 20 2008 [2621640 80] 5G.1;1
-- 000 1073743872 May 20 2008 [4718791 00] 5G.1;1
-- 000 9663674368 May 20 2008 [ 24 00] 5G.1;1
-- 000 1073743872 May 20 2008 [2097175 00] 5G000.0;1
It depicts that 9GB file consists of 3 extents, 1st starting at LBA 24,
2nd at 2621640, and finally 3rd one at 4718791. But where does first
extent end? At 24 + 4294965248 / 2048 = 2097175, which is more than 1GB
apart from start of 2nd extent.
P.S.: The solution to correctly import directory entries from old sessions is
not trivial but a first hacky solution seems to work
Just for reference, attached patch would handle even shrinking
multi-extent files. Once again I want to point out that I make no claims
that the patches are complete solution to the problem. Their purpose is
to support claims in original bug report. A.
--- ./mkisofs/multi.c.orig 2007-08-20 18:17:17.0 +0200
+++ ./mkisofs/multi.c 2008-05-23 14:05:38.0 +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;
@@ -947,6 +963,7 @@
{
int i;
int rr;
+ int same;
int retcode = 0; /* Default not found */
for (i = 0; i len; i++) {
@@ -996,6 +1013,7
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Andy Polyakov [EMAIL PROTECTED] wrote: I cannot speak for the sofware you used to look at the image. In other words you're implying that under no circumstances results obtained with software of my choice could be possibly right. I cannot confirm your claims as I cannot see any hint that would prove it. P.S.: The solution to correctly import directory entries from old sessions is not trivial but a first hacky solution seems to work Just for reference, attached patch would handle even shrinking multi-extent files. Once again I want to point out that I make no claims that the patches are complete solution to the problem. Their purpose is to support claims in original bug report. A. Your new patch still is not correct: - It does not honor the data structures from mkisofs - It does not copy over the block addresses from the old directory entries. - It does not take care of the probability that the old session might have been created by other software or by a mkisofs version that uses different parameters for multi-extent files. I put out a new mkisofs version that supports multi-extent files in multi-session mode. Please try the latest schily source consolidation from ftp://ftp.berlios.de/pub/schily/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Andy Polyakov [EMAIL PROTECTED] wrote: 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. The reason is in the beginning of merge_isofs() in multi.c. In particular for (i=0;i100;i++) loop. As area prior sector 16 is allowed to be and customarily used for other purposes (such as hybrid disks), there is no guarantee that data there does not resemble iso9660 volume descriptor. I don't want mkisofs to look at sectors prior 16th at all, but start directly with volume descriptor. One can argue that mkisofs should have seek-ed to 16th sector all by itself, but the code has been around for so long, that it should be considered feature, not bug. In theory, I could change mkisofs to start looking at sector #16 as the oldest availabe implementation (20 years old) at http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/hsfs/hsfs_vnops.c starts reading at sector 16. But if you put something that looks like a PVD between sector #0 and sector #15, then your software is wrong anyway. Are you really doing this? Your claim that the file is non-contiguous is just wrong. Having 9GB 5G.0 file in XP (previously discussed), if I read byte prior 4GB-2KB offset in the file, I get last byte from LBA X+0x20-2, and when I read next byte, i.e. at 4GB-2KB offset in file I get data from LBA Y, and there is 1GB gap between X+0x20 and Y. A. I cannot speak for the sofware you used to look at the image. I looked at my test results using isoinfo and isoinfo did not show non-contiguous files. P.S.: The solution to correctly import directory entries from old sessions is not trivial but a first hacky solution seems to work PP.S.: I recently tried to start a mkisofs related discussion and it turns out that some of the affected code is from you. Could you comment whether it would be possible to keep PREP Boot support without including Apple hfs? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Joerg Schilling wrote: Andy Polyakov [EMAIL PROTECTED] wrote: 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. The reason is in the beginning of merge_isofs() in multi.c. In particular for (i=0;i100;i++) loop. As area prior sector 16 is allowed to be and customarily used for other purposes (such as hybrid disks), there is no guarantee that data there does not resemble iso9660 volume descriptor. I don't want mkisofs to look at sectors prior 16th at all, but start directly with volume descriptor. One can argue that mkisofs should have seek-ed to 16th sector all by itself, but the code has been around for so long, that it should be considered feature, not bug. In theory, I could change mkisofs to start looking at sector #16 as the oldest availabe implementation (20 years old) at http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/hsfs/hsfs_vnops.c starts reading at sector 16. But if you put something that looks like a PVD between sector #0 and sector #15, then your software is wrong anyway. Are you really doing this? I would think that since you don't want to use anything resembling a PVD found in that range, any application would be more robust not to look at all. Who knows what a hybrid disk might contain? -- Bill Davidsen [EMAIL PROTECTED] Woe unto the statesman who makes war without a reason that will still be valid when the war is over... Otto von Bismark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Bill Davidsen [EMAIL PROTECTED] wrote: The second step will be to make retained multi-extent files correclty in the next session. If there is a remaining problem, lets see. I have no problem with following correct steps in order. I think there's a problem with large files being smaller, but I may not have explained it clearly. I did already explain that a _changed_ file is an unrelated new/different case. The current case is about retainung multi-extent files from older sessions. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Andy Polyakov [EMAIL PROTECTED] wrote: Exhibit #7. 'isoinfo -l -T -i /dev/dvd' output for same recording: Directory listing of / d- 000 2048 May 20 2008 [2621639 02] . d- 000 2048 May 20 2008 [2621639 02] .. -- 000 5368709120 May 20 2008 [ 24 80] 5G.0;1 -- 000 5368709120 May 20 2008 [2621640 80] 5G.1;1 BTW: If you did use -debug, you could see all directory entries + the sum entry. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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. The reason is in the beginning of merge_isofs() in multi.c. In particular for (i=0;i100;i++) loop. As area prior sector 16 is allowed to be and customarily used for other purposes (such as hybrid disks), there is no guarantee that data there does not resemble iso9660 volume descriptor. I don't want mkisofs to look at sectors prior 16th at all, but start directly with volume descriptor. One can argue that mkisofs should have seek-ed to 16th sector all by itself, but the code has been around for so long, that it should be considered feature, not bug. Your claim that the file is non-contiguous is just wrong. Having 9GB 5G.0 file in XP (previously discussed), if I read byte prior 4GB-2KB offset in the file, I get last byte from LBA X+0x20-2, and when I read next byte, i.e. at 4GB-2KB offset in file I get data from LBA Y, and there is 1GB gap between X+0x20 and Y. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Consider creating say 5GiB file and mastering an image: $ touch 5G.0 $ perl -e 'truncate(5G.0,5*1024*1024*1024)' $ ./mkisofs -iso-level 3 5G.0 1st.iso One does not have to wait till mkisofs completes, just press ctrl-c as soon as progress indicator goes off and examine directory table [in hex editor]. Directory table in 1st.iso contains following entries: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 This table describes contiguous 5GiB large file named 5G.0 consisting of two extents. X is extent beyond directory table in 1st.iso. So far so good. Now throw in another 5GiB file into second session: $ touch 5G.1 $ perl -e 'truncate(5G.1,5*1024*1024*1024)' $ ./mkisofs -C 16,2621614 -M 1st.iso -iso-level 3 5G.1 2nd.iso Again, one does not have to wait till mkisofs completes, just press ctrl-c as soon as progress indicator goes off and examine directory table [in hex editor]. Directory table in 2nd.iso comes out corrupted: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.1;1 0x804GB-2KB Y 5G.1;1 0x005GB-(4GB-2KB) Y+0x20-1 5G000.0;1 0x005GB-(4GB-2KB) X+0x20-1 This table describes fragmented 9GB-2KB file named either 5G.0 or 5G.1[?] and 1GB+2KB file named 5G000.0. Y is extent beyond directory table in 2nd.iso. Correct table for 2nd.iso would be: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 5G.1;1 0x804GB-2KB Y 5G.1;1 0x005GB-(4GB-2KB) Y+0x20-1 You used mkisofs incorrectly Command line sequence was *tailored* to allow to produce usable input for *hex editor* in less than minute. 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: Volume in drive D is CDROM Volume Serial Number is 7896-8AA6 Directory of D:\ 05/19/2008 04:09 PM 9,663,674,368 5G.0 05/19/2008 04:09 PM 1,073,743,872 5G000.0 2 File(s) 10,737,418,240 bytes 0 Dir(s) 0 bytes free Admittedly one can argue what does above mentioned sequence of directory records represent, but reported interpretation is *not* something I made up out of nowhere, it actually occurred. If c), then please suggest your sequence. You did however find a bug. It seems that mkisofs for some reason assigned new block addresses for old files. No. What apparently happens is following. As mkisofs -M reads 1st.iso it runs across two directory records describing two extents of 5G.0. As it pays no attention to ISO_MULTIEXTENT flag, it treats these two extents as two files with same name. Then it discovers name conflict and resolves it by renaming second extent to 5G000.0. It does *not* assign new block addresses for old files, as 'location of extent' values remain constant for original 5G.0 extents, corresponding directory records simply moved apart by directory record sorting algorithm. Latter means that it's perfectly possible to choose file names in such manner that recording will come out right [at least on XP]. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Andy Polyakov [EMAIL PROTECTED] wrote: 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. BTW: isoinfo gives you all information you need in order to debug the problem. I prefer to use official tools for debugging. 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 explained you that the problem is the incorrect allocation os _new_ space for the old file. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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- 000 2048 May 20 2008 [ 23 02] .
d- 000 2048 May 20 2008 [ 23 02] ..
-- 000 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 -i /dev/dvd' output for same recording:
Directory listing of /
d- 000 2048 May 20 2008 [2621639 02] .
d- 000 2048 May 20 2008 [2621639 02] ..
-- 000 9663674368 May 20 2008 [ 24 80] 5G.1;1
-- 000 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 -i /dev/dvd' output for same recording:
Directory listing of /
d- 000 2048 May 20 2008 [2621639 02] .
d- 000 2048 May 20 2008 [2621639 02] ..
-- 000 5368709120 May 20 2008 [ 24 80] 5G.0;1
-- 000 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.0 +0200
+++ ./mkisofs/multi.c 2008-05-20 19:20:53.0 +0200
@@ -538,6 +538,7 @@
unsigned char *tt_buf;
UInt32_ttt_extent;
UInt32_ttt_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 =
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Andy Polyakov [EMAIL PROTECTED] wrote: 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? Mmm I see no relation to the problem: you used -C16 isntead of -C0 I thought this is something you should know. 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... I don't understand you. Your claim that the file is non-contiguous is just wrong. I explained the real problem and I am trying to fix the problem since yesterday evening. 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. You look frustrated, why? 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. Your patch is not correct at all although you started changing at the right location ;-) Only a setting up correct multi-extent file directory entry will work correctly. I stared working already on a correct solution today but setting up the correct data structures takes a lot more than just 5 lines of code. After my solution is ready, we still need some testing Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Joerg Schilling wrote: Andy Polyakov [EMAIL PROTECTED] wrote: 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? Mmm I see no relation to the problem: you used -C16 isntead of -C0 I thought this is something you should know. 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... I don't understand you. Your claim that the file is non-contiguous is just wrong. I explained the real problem and I am trying to fix the problem since yesterday evening. 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. You look frustrated, why? 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. Your patch is not correct at all although you started changing at the right location ;-) Only a setting up correct multi-extent file directory entry will work correctly. I'm curious how you handle the case where the file shrinks and no longer needs multi-extent. I hope that's clear, I don't have a better description at hand. I stared working already on a correct solution today but setting up the correct data structures takes a lot more than just 5 lines of code. After my solution is ready, we still need some testing Jörg -- Bill Davidsen [EMAIL PROTECTED] Woe unto the statesman who makes war without a reason that will still be valid when the war is over... Otto von Bismark
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Bill Davidsen [EMAIL PROTECTED] wrote: Only a setting up correct multi-extent file directory entry will work correctly. I'm curious how you handle the case where the file shrinks and no longer needs multi-extent. I hope that's clear, I don't have a better description at hand. The best solution for problems is to handle unrelated things independently. The first step was to implement multi-extent files correctly. The second step will be to make retained multi-extent files correclty in the next session. If there is a remaining problem, lets see. Doing things correct may look as if it takes more time than doing things quickly but it finally wins. I will continue to do things right with mkisofs rather than trying to find quick ways to hide problems at first sight (as done in genisoimage). Users of my software can rely on me taking things seriously. In the long term, I will be able to keep software maintainable that's what finally counts what's important for me. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Joerg Schilling wrote: Bill Davidsen [EMAIL PROTECTED] wrote: Only a setting up correct multi-extent file directory entry will work correctly. I'm curious how you handle the case where the file shrinks and no longer needs multi-extent. I hope that's clear, I don't have a better description at hand. The best solution for problems is to handle unrelated things independently. The first step was to implement multi-extent files correctly. The second step will be to make retained multi-extent files correclty in the next session. If there is a remaining problem, lets see. I have no problem with following correct steps in order. I think there's a problem with large files being smaller, but I may not have explained it clearly. Doing things correct may look as if it takes more time than doing things quickly but it finally wins. I will continue to do things right with mkisofs rather than trying to find quick ways to hide problems at first sight (as done in genisoimage). Users of my software can rely on me taking things seriously. In the long term, I will be able to keep software maintainable that's what finally counts what's important for me. Jörg -- Bill Davidsen [EMAIL PROTECTED] Woe unto the statesman who makes war without a reason that will still be valid when the war is over... Otto von Bismark
mkisofs -M makes no attempt to reconstruct multi-extent files
$ ./mkisofs -v mkisofs 2.01.01a39 ... Consider creating say 5GiB file and mastering an image: $ touch 5G.0 $ perl -e 'truncate(5G.0,5*1024*1024*1024)' $ ./mkisofs -iso-level 3 5G.0 1st.iso One does not have to wait till mkisofs completes, just press ctrl-c as soon as progress indicator goes off and examine directory table [in hex editor]. Directory table in 1st.iso contains following entries: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 This table describes contiguous 5GiB large file named 5G.0 consisting of two extents. X is extent beyond directory table in 1st.iso. So far so good. Now throw in another 5GiB file into second session: $ touch 5G.1 $ perl -e 'truncate(5G.1,5*1024*1024*1024)' $ ./mkisofs -C 16,2621614 -M 1st.iso -iso-level 3 5G.1 2nd.iso Again, one does not have to wait till mkisofs completes, just press ctrl-c as soon as progress indicator goes off and examine directory table [in hex editor]. Directory table in 2nd.iso comes out corrupted: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.1;1 0x804GB-2KB Y 5G.1;1 0x005GB-(4GB-2KB) Y+0x20-1 5G000.0;1 0x005GB-(4GB-2KB) X+0x20-1 This table describes fragmented 9GB-2KB file named either 5G.0 or 5G.1[?] and 1GB+2KB file named 5G000.0. Y is extent beyond directory table in 2nd.iso. Correct table for 2nd.iso would be: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 5G.1;1 0x804GB-2KB Y 5G.1;1 0x005GB-(4GB-2KB) Y+0x20-1 A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Hi, 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 as an interested bystander i wonder how it is about general mountability of this image. Is this supported in contemporary Linux ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 as an interested bystander i wonder how it is about general mountability of this image. Is this supported in contemporary Linux ? Define supported. Multi-extent files are recognized by isofs module and simple tests like above do pass... This does not exclude possibility for breakage in some situation[s]... Multi-extent support is actually rather old in Linux... A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Andy Polyakov [EMAIL PROTECTED] wrote: $ ./mkisofs -v mkisofs 2.01.01a39 ... Consider creating say 5GiB file and mastering an image: $ touch 5G.0 $ perl -e 'truncate(5G.0,5*1024*1024*1024)' $ ./mkisofs -iso-level 3 5G.0 1st.iso One does not have to wait till mkisofs completes, just press ctrl-c as soon as progress indicator goes off and examine directory table [in hex editor]. Directory table in 1st.iso contains following entries: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 This table describes contiguous 5GiB large file named 5G.0 consisting of two extents. X is extent beyond directory table in 1st.iso. So far so good. Now throw in another 5GiB file into second session: $ touch 5G.1 $ perl -e 'truncate(5G.1,5*1024*1024*1024)' $ ./mkisofs -C 16,2621614 -M 1st.iso -iso-level 3 5G.1 2nd.iso Again, one does not have to wait till mkisofs completes, just press ctrl-c as soon as progress indicator goes off and examine directory table [in hex editor]. Directory table in 2nd.iso comes out corrupted: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.1;1 0x804GB-2KB Y 5G.1;1 0x005GB-(4GB-2KB) Y+0x20-1 5G000.0;1 0x005GB-(4GB-2KB) X+0x20-1 This table describes fragmented 9GB-2KB file named either 5G.0 or 5G.1[?] and 1GB+2KB file named 5G000.0. Y is extent beyond directory table in 2nd.iso. Correct table for 2nd.iso would be: file name flags data length location of extent 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 5G.1;1 0x804GB-2KB Y 5G.1;1 0x005GB-(4GB-2KB) Y+0x20-1 You used mkisofs incorrectly and you seem to missinterpret the results from the tool you used to list ISO-9660 directories. You did however find a bug. It seems that mkisofs for some reason assigned new block addresses for old files. It will take some time to find the reason as there are 4 possible different places that could be the problem. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Thomas Schmitt [EMAIL PROTECTED] wrote: Hi, 5G.0;1 0x804GB-2KB X 5G.0;1 0x005GB-(4GB-2KB) X+0x20-1 as an interested bystander i wonder how it is about general mountability of this image. Is this supported in contemporary Linux ? A year ago, it did not work correctly. It now seems to work. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
