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