I've tried extracting it via unzip, tar, and the built in macOS GUI unzipper, and all three respect the permissions specified which cause permissions errors on unix. Being that this release is to help fix something for non-windows users, it'll be hard for them to use any of the artifacts besides the nupkg (which is likely the more frequently used artifact I'd imagine). Doing a zipinfo on the nupkg file notes that it's encoded using zip 2.0 in fat permissions format while the source and binary zips are encoded from zip 6.3 in unix permissions format.
What you might want to figure out is how to make the win32 zippers _not_ add unix permissions since they're doing it wrong. :) On Sun, 18 Oct 2020 at 13:55, Davyd McColl <dav...@gmail.com> wrote: > > Hi Matt > > Zip files are created from windows as there are certain targets that Unix > compiles can't hit (specifically < net40 and client profiles), which would > probably explain the permissions. Not a lot I can do about it though, that I > know of. If it's an issue and someone knows how to convince win32 zippers to > do Unix permissions, I'm all ears. > > -d > > On October 18, 2020 20:07:18 Matt Sicker <boa...@gmail.com> wrote: >> >> Signatures and checksums are good. Once I extracted the zips, though, >> I see they have some strange permissions configured. All the >> directories have a chmod of rw-rw-rw (just like all the files do), but >> they should be rwxr-xr-x. Example output from zipinfo comparing >> log4net zip with log4j zip: >> >> Archive: apache-log4j-2.13.3-bin.zip >> Zip file size: 14581816 bytes, number of entries: 74 >> drwxr-xr-x 2.0 unx 0 b- stor 20-May-10 12:06 apache-log4j-2.13.3-bin/ >> -rw-r--r-- 2.0 unx 2888 bl defN 20-May-10 11:56 >> apache-log4j-2.13.3-bin/RELEASE-NOTES.md >> ... >> >> Archive: apache-log4net-binaries-2.0.12.zip >> Zip file size: 2154452 bytes, number of entries: 28 >> drw-rw-rw- 6.3 unx 0 b- stor 20-Oct-18 17:22 net20/ >> ... >> -rw-rw-rw- 6.3 unx 262144 b- defN 20-Oct-18 17:22 net20/log4net.dll >> ... >> >> The directories need to be executable to be able to list files from >> them (Unix/POSIX). I'm not sure how these zip files got these >> permissions. I see that the previous 2.0.10 release of log4net has the >> same problem, though. >> >> On Sun, 18 Oct 2020 at 11:03, Davyd McColl <dav...@gmail.com> wrote: >>> >>> >>> Hi all >>> >>> Not much has changed in 2.0.12 except that an issue affecting non-windows >>> users has been addressed. LOG4NET-652 and LOG4NET-653 both stem from the >>> same source, wherein the username for the current logging thread was not >>> correctly retrieved on non-windows platforms and would throw a >>> PlatformNotSupported error. I was hoping that one of the authors of pull >>> requests to resolve this would respond to my comments on said pull >>> requests, but it's been a while now and there's been a user asking when the >>> update would be released, so, as much as I would have liked the community >>> member commits, I've gone ahead and applied the logic myself. >>> >>> Anyways, 2.0.12 is up for release at >>> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12 >>> [https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12] with >>> signed artifacts there. Documentation is updated at the staging site -- all >>> that's left is a sanity check and vote before I can push the nupkg to >>> nuget.org, which is how most people will consume it. >>> >>> Ralph, as far as I understand, I still don't have the ability to push >>> artifacts to the apache download server, so please could you do so for me? >>> >>> Thanks for your time >>> -d >> >> >> -- >> Matt Sicker <boa...@gmail.com> -- Matt Sicker <boa...@gmail.com>
