When editing a zip file created by a third party tool that wrote extra field data for any entry in the zip file, zipwriter will not correctly output the zip file leaving it unusable. The fix for this is fairly simple, not going to be prone to cause any regression and can easily be unit tested.
Created attachment 312356 [details] [diff] [review] patch rev 1 This is some poor code that went effectively untested because the extra field is unused by zipwriter which writes pure zip files. The already in tree testcase of this didn't flag any errors because every unit test removes existing things from it. This new unit test just adds something and checks that the file isn't corrupt (it is without this patch) and that the length is correct. The patch just properly uses the mFieldLength field to keep the length of the extrafield known.
Attachment #312356 - Flags: review?(benjamin)
Comment on attachment 312356 [details] [diff] [review] patch rev 1 a=beltzner
Attachment #312356 - Flags: approval1.9? → approval1.9+
Checking in modules/libjar/zipwriter/src/nsZipHeader.cpp; /cvsroot/mozilla/modules/libjar/zipwriter/src/nsZipHeader.cpp,v <-- nsZipHeader.cpp new revision: 1.2; previous revision: 1.1 done CS file: /cvsroot/mozilla/modules/libjar/zipwriter/test/unit/test_bug425768.js,v done Checking in modules/libjar/zipwriter/test/unit/test_bug425768.js; /cvsroot/mozilla/modules/libjar/zipwriter/test/unit/test_bug425768.js,v <-- test_bug425768.js initial revision: 1.1 done
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.