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.isoOne 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 0x80 4GB-2KB X 5G.0;1 0x00 5GB-(4GB-2KB) X+0x200000-1This 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.isoAgain, 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 0x80 4GB-2KB X 5G.1;1 0x80 4GB-2KB Y 5G.1;1 0x00 5GB-(4GB-2KB) Y+0x200000-1 5G000.0;1 0x00 5GB-(4GB-2KB) X+0x200000-1This 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 0x80 4GB-2KB X 5G.0;1 0x00 5GB-(4GB-2KB) X+0x200000-1 5G.1;1 0x80 4GB-2KB Y 5G.1;1 0x00 5GB-(4GB-2KB) Y+0x200000-1You 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.