zip64 archives - Archives larger than 4GB or with more than 2^32 entries.
extended timestamps - Higher resolution and in UTC.
UID/GID - Save and extract the original UID/GID.
Fixes so that permission mode attributes are correctly read and set for
files in archives.
zip:list_dir/2 now also returns directories, not only files. (You can disable this behaviour by using the option skip_directories).
All releases now have .zip versions of the Windows installer that can be used to install Erlang/OTP on Windows when you do not have administrator priviliges. You can download it from Downloads - Erlang/OTP or from Releases Ā· erlang/otp Ā· GitHub.
Various bugs in the original implementation have also been fixed, such as:
Correctly encoding and decoding the DOS timestamps for entries within an archive
(that is the non-extended timestamp).
Fixed DOS timestamps to be set to localtime instead of UTC (use extended
timestamps for UTC timestamps).
Used the unix file attributes read from disk when creating archives instead
of setting everything to 644.
Potential incompatibilities:
Progress reports for a dynamically started supervisor will now be logged at
debug level.
For details about bugfixes and potential incompatibilities see
the Erlang 27.1 README
The Erlang/OTP source can also be found at GitHub on the official Erlang repository,
Download links for this and previous versions are found here
Seems like either I or the tool that created those zip files have interpreted the zip64 standard incorrectly. As unix zip seems to be happy enough to extract these, Iām leaning towards me. When running zipinfo on test.xlsx it prints a lot of āThere are an extra XYZ bytes preceding this file.ā, which Iām guessing is the parts that are breaking things.
Thanks for the report, Iāll create a PR with a fix as soon as Iāve figured out what zip should do in these type of scenarios.
Hm, Iāve been having issues where previously working self-signed certificates seem to no longer be accepted, where I instead get an error:
=NOTICE REPORT==== 23-Sep-2024::09:46:04.205008 ===
TLS client: In state wait_cert at ssl_handshake.erl:2175 generated CLIENT ALERT: Fatal - Bad Certificate
- selfsigned_peer
Whatās interesting is that if I try to instrument my very_fun/3 function (which does certificate pinning), it does not even output anything, leading me to think thereās some weird issue with the new decoding and usage of verify_fun/4 bailing out before I can tell it itās actually okay?
That wasnāt very challenging to do with Kerl, I can confirm I managed to make it work without issues using Ingelaās patch.
(It also appears that regardless of my tests, I wouldnāt get output out of the very_fun functions, which is a bit funny but I imagine my user output got redirected at a place I didnāt expect in my release.)
