ZipDirectory on Linux/macOS produces zip with invalid file permissions on zip entries

[natemcmaster]

The ZipDirectory task, when run on Linux or MacOS, produces an invalid .zip which cannot be used on Linux or macOS. The Unix file permissions on the zip entries contain permissions set to "0000", which means the files cannot be read, deleted, or executed.

Steps to reproduce

Project file

<Project>
  <Target Name="Build">
    <ZipDirectory SourceDirectory="$(MSBuildThisFileDirectory)input/" DestinationFile="stuff.zip" />
  </Target>
</Project>

Directory contents:

$ ls -l input/
total 0
-rwxr-xr-x  1 namc  wheel  0 Nov 12 11:22 test.sh
-rw-r--r--  1 namc  wheel  0 Nov 12 11:22 test.txt

Command line

dotnet msbuild zip.proj
unzip stuff.zip -d extracted
ls -l extracted/

Expected behavior

<ZipDirectory> preserves Unix file permissions, or at the very least, set's a usable file permission like rw-r--r--

Actual behavior

No permissions are preserved. The default, 0000, is used instead.

$ ls -l extracted/
total 0
----------  1 namc  wheel  0 Nov 12 11:22 test.sh
----------  1 namc  wheel  0 Nov 12 11:22 test.txt

Environment data

dotnet msbuild -version output:

Microsoft (R) Build Engine version 15.9.19+g938f3292a0 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

15.9.19.36755

OS info: macOS Mojave

[rainersigwald]

We're a very thin wrapper on a corefx method there:

https://github.com/Microsoft/msbuild/blob/50dd97b58e94ee8e11e2be1aeafb71f9d0e25e88/src/Tasks/ZipDirectory.cs#L70

So I suspect this bug should be moved to corefx, but I haven't written a tiny repro outside of MSBuild to confirm.

[natemcmaster]

I suspect the root issue is https://github.com/dotnet/corefx/issues/17342. It might be possible to workaround for now on .NET Core by setting ZipEntry.ExternalAttributes manually. Example: https://github.com/aspnet/BuildTools/blob/de1bb36b23eb75fb46fec926391f9604140f6092/modules/BuildTools.Tasks/ZipArchive.cs#L93-L108