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: The future of mkisofs
Bill Davidsen [EMAIL PROTECTED] wrote: I happily offer the suggestion that since the program has not been limited to ISO9660 images for years, the name implies limitations which don't apply, and since you can create images for most common optical media, that a name like mkoptimage would be more correct as well as preventing confusion. mkisofs is a well known program name and I cannot see that your proposal for a name change could help to reduce confusion for users. The probably biggest help for _new_ users was to list only the most important options in case of a usage error: Most important Options: -posix-HFollow sylinks encountered on command line -posix-LFollow all symlinks -posix-PDo not follow symlinks (default) -o FILE, -output FILE Set output file name -R, -rock Generate Rock Ridge directory information -r, -rational-rock Generate rationalized Rock Ridge directory info -J, -joliet Generate Joliet directory information -print-size Print estimated filesystem size and exit -UDFGenerate UDF file system -dvd-video Generate DVD-Video compliant UDF file system -iso-level LEVELSet ISO9660 level (1..3) or 4 for ISO9660 v 2 -V ID, -volid IDSet Volume ID -graft-points Allow to use graft points for filenames -M FILE, -prev-session FILE Set path to previous session to merge to lead people to the right options. 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: Announcing xorriso-0.1.6
Bill Davidsen [EMAIL PROTECTED] wrote: This has been on my someday list for a while, does it have the capability of taking a bootable image, letting me change the non-boot files, and then giving me another burnable image? I'm thinking Linux install disks with the extras and upgrades added, to simplify creation. While I know how to make bootable media, from scratch if need be, I don't much enjoy the steps. :-( This will not work without non-artficial intelligence as you need tricks to make a CD boot on every BIOS. The best way to re-create a bootable CD is to manually find the boot image first. This can be done by calling isodebug: isodebug -i /tmp/sol-nv-b87-x86-dvd.iso ISO-9660 image created at Mon Apr 7 12:32:02 2008 Cmdline: 'mkisofs 2.01 -b boot/grub/stage2_eltorito -c .catalog -no-emul-boot -boot-load-size 4 -boot-info-table -relaxed-filenames -l -ldots -r -N -d -D -V SOL_11_X86 -o .../solarisdvd.iso .../solarisdvd.product' As yoou see, the boot image is boot/grub/stage2_eltorito, however only the first 2048 bytes of this file are announced in the ElTorito header: isoinfo -d -i /tmp/sol-nv-b87-x86-dvd.iso CD-ROM is in ISO 9660 format System id: Solaris Volume id: SOL_11_X86 Volume set id: Publisher id: Data preparer id: Application id: MKISOFS ISO 9660/HFS FILESYSTEM BUILDER CDRECORD CD-R/DVD CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 1984486 El Torito VD version 1 found, boot catalog is in sector 10559 NO Joliet present Rock Ridge signatures version 1 found Eltorito validation header: Hid 1 Arch 0 (x86) ID '' Key 55 AA Eltorito defaultboot header: Bootid 88 (bootable) Boot media 0 (No Emulation Boot) Load segment 0 Sys type 0 Nsect 4 Bootoff 2940 10560 What you see with this output is that the file /boot/grub/stage2_eltorito starts at Sector # 10560. As ElTorito only announces 2048 bytes from: -r--r--r-- 100 133008 Apr 2 2008 [ 10560 00] stage2_eltorito (this output if from isoinfo -i /tmp/sol-nv-b87-x86-dvd.iso -lR) it is obvious that any automated attempt to re-create a bootable DVD from the Solaris install DVD will not work. BTW: Linux CDs/DVDs look very similar. 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: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Dave Platt [EMAIL PROTECTED] wrote: The problem is that they have called wodim cdrecord and provided (or in some cases not) different functionality. Obviously distributions thought people wouldn't use it if people knew it was another program. I feel the same way as I do when I order coke and get pepsi, it's a scam. I can't speak for the people who put together the distributions, but I'm not at all convinced about the Obviously. I suspect that the larger motivation was Don't break existing scripts, don't break existing GUI front-end applications. They definitely broke existing GUI as the original cdrecord works while wodim does not work in many cases. The Authors from k3b even started to look for the original cdrecord to be able to use this instead of the plagiat. 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: Announcing xorriso-0.1.6
Thomas Schmitt [EMAIL PROTECTED] wrote: Hi, does it have the capability of taking a bootable image, letting me change the non-boot files, and then giving me another burnable image? We strive for that. From the man page: -boot_image any|isolinux discard|keep|patch A man page is not sufficient. In order to test things, I would like to to see compilable code ;-) 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: Announcing xorriso-0.1.6
--- Em seg, 19/5/08, Thomas Schmitt [EMAIL PROTECTED] escreveu: I don't know whether a bootable appendable media stays bootable with -dev /dev/cdrom rather than -indev ... -outdev ... . This would add a session to the media. The session would hold a new directory tree, a new boot sector and the data blocks of the new or overwritten files. An image that remains bootable with -indev -outdev should remain bootable with -dev too (Note we only deal with el-torito images). El-Torito has specific support for multisession images, it tries to locate a valid boot sector in the last session. On emulated multisession (such as DVD+RW) the new boot sector is placed propertly at the begining of the image, so it works too. As far as I know, to keep the image bootable: - We have to figure out the size of the boot image (this means, it must appear in the ISO-9660 directory tree), - The boot image should work with the newly generated directory tree. This is the hard point. A boot image is arbitrary executable code that gets loaded into RAM at boot time and then executed. If that code assumes some disc directory structure, it won't work, unless we were clever enought to modify the code propertly. At this time, libisofs is only able to modify isolinux code, but it cannot detect a boot image is isolinux, so you need to tell it about that, with isolinux and patch options. Cheers, Vreixo Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The future of mkisofs
Joerg Schilling wrote: Bill Davidsen [EMAIL PROTECTED] wrote: I happily offer the suggestion that since the program has not been limited to ISO9660 images for years, the name implies limitations which don't apply, and since you can create images for most common optical media, that a name like mkoptimage would be more correct as well as preventing confusion. mkisofs is a well known program name and I cannot see that your proposal for a name change could help to reduce confusion for users. Wow, think about that! You have to tell people many times a month that the program called cdrecord in many distributions is really wodin and works differently than your original cdrecord. Do you really want to be bothered by having questions about *three* versions of mkisofs, the current one in a38, the old one shipped with some distributions, and your new cleaned up version? It sounds like a waste of your time to me! And as for user confusion, I always install current cdrecord as CDrecord so I won't get the one which comes with a distribution. It would help the users if you did that with the enhanced mkisofs, because they wouldn't use an old version and complain, or try to use features in the new version and find they don't work. You know that no matter how confused the user is, it always gets reported as bug in your software. Best of both worlds, you don't get questions caused by users confusion, waste time chasing bugs that aren't, and users know what they are getting. The probably biggest help for _new_ users was to list only the most important options in case of a usage error: Most important Options: -posix-HFollow sylinks encountered on command line -posix-LFollow all symlinks -posix-PDo not follow symlinks (default) -o FILE, -output FILE Set output file name -R, -rock Generate Rock Ridge directory information -r, -rational-rock Generate rationalized Rock Ridge directory info -J, -joliet Generate Joliet directory information -print-size Print estimated filesystem size and exit -UDFGenerate UDF file system -dvd-video Generate DVD-Video compliant UDF file system -iso-level LEVELSet ISO9660 level (1..3) or 4 for ISO9660 v 2 -V ID, -volid IDSet Volume ID -graft-points Allow to use graft points for filenames -M FILE, -prev-session FILE Set path to previous session to merge to lead people to the right options. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing xorriso-0.1.6
Joerg Schilling wrote: Bill Davidsen [EMAIL PROTECTED] wrote: This has been on my someday list for a while, does it have the capability of taking a bootable image, letting me change the non-boot files, and then giving me another burnable image? I'm thinking Linux install disks with the extras and upgrades added, to simplify creation. While I know how to make bootable media, from scratch if need be, I don't much enjoy the steps. :-( This will not work without non-artficial intelligence as you need tricks to make a CD boot on every BIOS. My assumption is that if you start with a working bootable media, all you have to do is find out what tricks were used in the first place. As you note below you can get that information from isoinfo, and since you are changing the content rather than the boot logic or image you just need to keep what you have. I was more aiming this at xorriso, since that already does most of what's needed, and Thomas may be more inclined to prove it can be done than explain why it can't. Clearly making a bootable CD is very easy, since I have done it just by following the explanation you made in an early man page, and knowing that the the boot block in eltorito is just a floppy image, which happens to be the largest size you can fit on a standard floppy using four 32k sectors per track, or maybe eight 16k with a short IRG. I appreciate that you are mentioning all the odd case which are difficult, but if eltorito boot can be done correctly, and other boot methods are rejected, that would still be useful. The best way to re-create a bootable CD is to manually find the boot image first. This can be done by calling isodebug: isodebug -i /tmp/sol-nv-b87-x86-dvd.iso ISO-9660 image created at Mon Apr 7 12:32:02 2008 Cmdline: 'mkisofs 2.01 -b boot/grub/stage2_eltorito -c .catalog -no-emul-boot -boot-load-size 4 -boot-info-table -relaxed-filenames -l -ldots -r -N -d -D -V SOL_11_X86 -o .../solarisdvd.iso .../solarisdvd.product' As yoou see, the boot image is boot/grub/stage2_eltorito, however only the first 2048 bytes of this file are announced in the ElTorito header: isoinfo -d -i /tmp/sol-nv-b87-x86-dvd.iso CD-ROM is in ISO 9660 format System id: Solaris Volume id: SOL_11_X86 Volume set id: Publisher id: Data preparer id: Application id: MKISOFS ISO 9660/HFS FILESYSTEM BUILDER CDRECORD CD-R/DVD CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 1984486 El Torito VD version 1 found, boot catalog is in sector 10559 NO Joliet present Rock Ridge signatures version 1 found Eltorito validation header: Hid 1 Arch 0 (x86) ID '' Key 55 AA Eltorito defaultboot header: Bootid 88 (bootable) Boot media 0 (No Emulation Boot) Load segment 0 Sys type 0 Nsect 4 Bootoff 2940 10560 What you see with this output is that the file /boot/grub/stage2_eltorito starts at Sector # 10560. As ElTorito only announces 2048 bytes from: -r--r--r-- 100 133008 Apr 2 2008 [ 10560 00] stage2_eltorito (this output if from isoinfo -i /tmp/sol-nv-b87-x86-dvd.iso -lR) it is obvious that any automated attempt to re-create a bootable DVD from the Solaris install DVD will not work. BTW: Linux CDs/DVDs look very similar. I appreciate the warning, but doing the common case right and avoiding doing the other cases wrong is still useful. -- 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: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Joerg Schilling wrote: Dave Platt [EMAIL PROTECTED] wrote: The problem is that they have called wodim cdrecord and provided (or in some cases not) different functionality. Obviously distributions thought people wouldn't use it if people knew it was another program. I feel the same way as I do when I order coke and get pepsi, it's a scam. I can't speak for the people who put together the distributions, but I'm not at all convinced about the Obviously. I suspect that the larger motivation was Don't break existing scripts, don't break existing GUI front-end applications. They definitely broke existing GUI as the original cdrecord works while wodim does not work in many cases. I can't say many cases, but there are some burners which work better (ie produce useful burns) with cdrecord from Joerg. That said, in most cases wodim will work with good media and hardware. The Authors from k3b even started to look for the original cdrecord to be able to use this instead of the plagiat. Fewer complaints to them, I would think. -- 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: The future of mkisofs
Bill Davidsen [EMAIL PROTECTED] wrote: mkisofs is a well known program name and I cannot see that your proposal for a name change could help to reduce confusion for users. Wow, think about that! You have to tell people many times a month that the program called cdrecord in many distributions is really wodin and works differently than your original cdrecord. Do you really want to be bothered by having questions about *three* versions of mkisofs, the current one in a38, the old one shipped with some distributions, and your new cleaned up version? It sounds like a waste of your time to me! I don't see three versions of mkisofs as I know from several professional users of mkisofs that they don't use the hsfs feature. ... and the main difference I see between mkisofs and the clone from cdrkit is the bugs that are present in the clone but not in the original. 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: Announcing xorriso-0.1.6
Hi, I was more aiming this at xorriso, Any testing and report is appreciated. Re-reading my first answer it comes to me that it will work better with a single drive if you copy the existing image from media to disk and use the burner rather for writing directly to the media. Like : $ dd if=/dev/sr0 of=/my/dd/copy/of/image ... $ xorriso \ -indev stdio:/my/dd/copy/of/image \ -outdev /dev/sr0 \ ... As Vreixo confirmed, it would also work with an appendable or overwriteable media holding the previous bootable ISO session: $ xorriso -dev /dev/sr0 ... since that already does most of what's needed, and Thomas may be more inclined to prove it can be done than explain why it can't. About insight and explanation i better point to Vreixo, who does development in libisofs. xorriso just uses two API calls to tell libisofs to patch or to discard the boot image which was found when loading the previous ISO session. The user tells xorriso whether patching seems worthwhile. 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
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: Announcing xorriso-0.1.6
Bill Davidsen [EMAIL PROTECTED] wrote: My assumption is that if you start with a working bootable media, all you have to do is find out what tricks were used in the first place. As you note below you can get that information from isoinfo, and since you are changing the content rather than the boot logic or image you just need to keep what you have. I was more aiming this at xorriso, since that already does most of what's needed, and Thomas may be more inclined to prove it can be done than explain why it can't. I cannot compile it so I cannot comment ;-) 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. 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
