Cœur

Ah, I missed the `--install` in your command: I never used that before. I'll ping those who wrote the lines you pointed at: @prateek9623 @leha-bot @kschwarz-intrepidcs @nmoinvaz

If I'm not mistaken, it's just about increasing this value: https://github.com/transmission/transmission/blob/ec5296c8dc15c0d51014d67ef93658e5569f354c/macosx/ProgressGradients.mm#L10-L15

Feel free to review #254

My PR adds a GitHub Action that validates that it works for all supported platforms (ubuntu, windows, macos). Apart from a paragraph in the Readme, can you clarify what else...

Note here, regarding my participation to this topic: I'm not advocating removing anything. I'm just offering to add cmake support through my pull request.

Could be a bug in SharpZipLib. But to help here, someone made #640 in order to make zip64 optional instead of systematic.

I changed zip64 logic to be "AUTO": it will only use zip64 when the size needs it.

To explain the current difference between **unx** and **osx**. The "version_madeby" is configured differently in two places ### When writing a file to an archive: https://github.com/ZipArchive/ZipArchive/blob/be6ac340cbe394cc6a81eae6034a91a7702d9db3/SSZipArchive/SSZipArchive.m#L1325-L1326 That is coming from...

So we have three tasks: - look into the executable permissions issue when version_madeby is UNIX (3) or OSX (19). - look into unicode filename support when version_madeby is UNIX...

First, I checked the doc: https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT >4.4.2.1 The upper byte indicates the compatibility of the file attribute information. >4.4.2.3 The lower byte indicates the ZIP specification version (the version of...