Closed mintern closed 2 years ago
I fixed both the issues you mentioned (including the one where ZipParameters.setLastModifiedTime
doesn't clear the time). I modified your test case slightly and used it in the project. Thanks for the detailed issue report, I appreciate that.
Thank you for the quick fix! I'm glad my report and sample test were useful.
I'm not seeing any ZipParameters.setLastModifiedFileTime
change (perhaps it wasn't git add
ed?), but that was just an aside on my part. You fixed the issue that I was running into.
Thanks again!
Thanks for pointing out. I fixed it.
Fix included in v2.11.2 released today
As of 2.11.0, file entries added via
putNextEntry
have a last modified date of 1980 whenZipParameters
are passed with the defaultlastModifiedFileTime == 0
value. https://github.com/srikanth-lingala/zip4j/commit/0f9901076d10f4fd4319d3ee3eb1d00f136f581e removed some conditional logic fromFileHeaderFactory.generateFileHeader
:This logic was added to
putNextEntry
instead, but only for directory entries:As a result, the following test, which passes for 2.10.0, fails for 2.11.0 and 2.11.1:
Was this change intended as part of the fix to #434, or was this an unintended side effect?
The documentation for
ZipParameters.setLastModifiedTime
says:but the current time is not being used for file entries when
zipParams.getLastModifiedFileTime() <= 0
like it used to.(I noticed a separate potential bug where
ZipParameters.setLastModifiedTime
just returns whenlastModifiedFileTime <= 0
. It doesn't actually clear the current value as the documentation indicates.)