Re: mkisofs -M makes no attempt to reconstruct multi-extent files
Andy Polyakov <appro@fy.chalmers.se> 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;i<100;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+0x200000-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+0x200000 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: