Support parameter files using Zip64 - #144
Conversation
|
There's also a bit of an annoying warning from |
|
Hey @sitch, thanks for the PR! We definitely should fix the warning, in our case it will produce a bunch of logs (since the archive usually has a lot of files) and it will confuse users. I see it's specifically the case where modification time/date is zero, so maybe it would make sense to special case that here and just return the earliest date. Do you want to ask/patch upstream? Alternatively we can try a different package. As for the test, I don't think it's worth using LFS. We should be good as long as existing tests pass and we know we can read any zip64 file :) |
|
@jonatanklosko I opened an issue akash-akya/unzip#17 to deal with the superfluous warnings. As for the test, do you want me to keep the existing code which only runs the test if a user manually runs |
|
Thanks! I don't think we need the additional test in this case; as long as we use a library with zip64 support and have tests for regular zips, it should be all good :) |
|
@jonatanklosko this PR is ready to merge.
|
2 participants
I added a test for the zip64 functionality, but due to requiring a >2GB binary fixture, I think including it in git LFS storage is a bit excessive. More than happy to remove these extra code bits.