Plugin shouldn't rebuild the original ZIP silently
Closed this issue · 3 comments
I've run into a weird problem related to GraalVM's native-image when using this plugin. Weird because my assumption had been "it just prepends a few bytes to the original file, what could possibly go wrong", but actually it rebuilds the whole ZIP from scratch and may introduce Zip64 format when doing so.
This was added in 94051ac by @wendigo and it's unclear to me why this plugin should do anything like that. The only benefit I see is that it can be idempotent (i.e. doesn't stupidly prepend the same bytes again when called repeatedly).
The format change may be useful in some scenarios, but those seem completely independent of making it "really executable". Am I missing something here? Perhaps this behaviour should be explicitly enabled by a flag?
Am I missing something here?
OK, after some testing, I get it: the naive "prepend bytes" approach doesn't work with Zip64 files. At least the JDK can't cope with that.
@klausbrunner that's correct. The "ordinary" prepend wouldn't work for ZIP64 files
@wendigo I've taken a trip down that particular rabbit hole, which resulted in some code to avoid rebuilding the archive, yet ending up with proper offsets: https://github.com/KlausBrunner/zip-prefixer - it's not exactly production quality yet but better tested than some ZIP implementations (which sadly isn't too difficult).
The main takeaway is that the "ordinary" prepend will screw up all archives, ZIP64 or not, because the internal offsets are wrong. However, most ZIP implementations (including the JDK's) can deal with that in the non-ZIP64 case. ZIP64 just introduces a bunch of additional indirections.