Zip.zip removes all file permissions on linux/mac

[sriv]

Description

Creating an archive using Zip.zip api, causes all file permissions to be lost on linux/macos.

Repro steps

Build Target source:

Target.create "Package" (fun _ ->
    !! ("artifacts/gauge-csharp/**/*")
    -- ("artifacts/gauge-csharp/tests/**/*")
    -- ("artifacts/gauge-csharp/itests/**/*")
    -- ("**/*.zip")
    |> Zip.zip "artifacts/gauge-csharp/" (sprintf @"artifacts/gauge-csharp/gauge-csharp-%s.zip" version)
)

Travis Build Logs:

https://travis-ci.org/getgauge/gauge-csharp/builds/401621274

Observe the below:

1. ls original content: https://travis-ci.org/getgauge/gauge-csharp/jobs/401621276#L3066

2. create the archive: https://travis-ci.org/getgauge/gauge-csharp/jobs/401621276#L3065

3. extract archive: https://travis-ci.org/getgauge/gauge-csharp/jobs/401621276#L3080

4. inspect extracted files: https://travis-ci.org/getgauge/gauge-csharp/jobs/401621276#L3141

Please provide the steps required to reproduce the problem

On Linux/macOS :

1. git clone https://github.com/getgauge/gauge-csharp -b 137

2. ./build.sh -t Package

3. check original permissions: ls -al artifacts/gauge-csharp

4. unzip artifacts/gauge-csharp/gauge-csharp-0.10.5.zip -d artifacts/gauge-csharp/out

5. ls -al artifacts/gauge-csharp/out

Expected behavior

The file permissions should be the same before and after archiving.

Actual behavior

Extracted contents lose all file permissions:

drwxrwxr-x  4 travis travis 4096 Jul  9 05:43 .
drwxrwxr-x  7 travis travis 4096 Jul  9 05:43 ..
drwxrwxr-x 16 travis travis 4096 Jul  9 05:43 bin
----------  1 travis travis  550 Jul  9 05:42 csharp.json
----------  1 travis travis   58 Jul  9 05:42 run.sh
drwxrwxr-x  4 travis travis 4096 Jul  9 05:43 skel

Known workarounds

None, I am happy to try any suggestions.

Related information

• Operating system : Ubuntu / macOS
• Branch
• Mono 5.0.0
• .NET SDK: 2.1.301

[matthid]

Sadly this is afaik a limitation of the .net core framework. And I think there is an issue open for it.

I'm not 100% sure, but I think there is nothing we can do besides using 3rd party libs or our own zip reader/writer...

[sriv]

Thanks @matthid - I was going through the code of Fake.IO.Zip and figured that this is probably an upstream issue. I am temporarily resorting to using native zip invocation via the Process api. Not optimal, but it seems to be working.

I think I can close this issue, unless you need it to be tracked.

BTW, thanks for all the hard work. I just moved to Fake5 and I am impressed in the amount of details that you have put for migration. Cheers!

[matthid]

@sriv Yes we can close this here, but we should at least find the correct issue where this is tracked and link it here (or create a new one in the corefx repository if none exists).

[matthid]

The most relevant seems to be https://github.com/dotnet/corefx/issues/14853

But a lot of issues have popped up everywhere over time:

• https://github.com/dotnet/corefx/issues/15516
• Add a way to preserve or set file permissions on generated content dotnet/templating#1028
• https://github.com/dotnet/cli/issues/6438
• Executables restored from NuGet packages are no longer executable with .NET Core "2.0" NuGet/Home#4424
• Change default file permissions on Unix to 666 dotnet/coreclr#7995

My understanding is that most of the time they added a workaround to call chmod +x and closed the issue.

[matthid]

While I closed this: Changing the underlying implementation to one that supports this scenario is welcome and a PR would be merged. However it is out of scope for myself, but we can re-open if anyone starts to volunteer.