[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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;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.

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.


Reply to: