Fix wrong START offset

[fabiensanglard]

Problem 1: START is set before looking up zip64 extra field. This
can lead to unproper LHF offset in case where the first entry is
located further than 0xFFFFFFFF in the archive.

Problem 2: If the order of entries in the CD does not match the
order of the LFH (e.g: The first CD entry is not the first LFH in
the archive), file scanning discard previous entries and mark them
as prefix.

Solution: Leverage @cd to generate a better START offset.

[pmqs]

The intention of the change is fine.

Problem is - dealing with 64-bit values with this script is only partially working, so need to see the impact of this PR.

[fabiensanglard]

Even if it doesn't completely solve problem #1, it solves problem #2.
What should be the next step on my side to help this CL to be merged?

[pmqs]

As it stands the fix does indeed fix problem 2, but only if the zip file isn't using the ZIP64 extension. I think the fix should be straightforward, so I can take care of it

[fabiensanglard]

Forgive me, I am a little slow :P. What prevents this pull request from being merged (a.k.a: I don't understand the "I can take care of it")?

[pmqs]

"I will take care of it" means that I will address the extra changes needed to get this PR to work with ZIP64 files. I not going to do that merge until

1. I'm clear what the extra changes are.

2. I have a zip file where the order of the entries in the central directory are not the same as the local area of the zip file.
   I know I have an example. I just need to find it.

[fabiensanglard]

Here is a zip where the LFH and the Central Directory entries order differ, just in case :) !

http://fabiensanglard.net/order.zip

Without the fix: 0000 PREFIX DATA PK........!.!.................c
With the fix: 0000 LOCAL HEADER #1 04034B50