Artifact zip uses chmod 0600, which some file managers dislike

[zwaldowski]

$ zipinfo Slides.zip
Archive:  /Users/zw/Downloads/Slides.zip
Zip file size: 30757126 bytes, number of entries: 2
-rw----     2.0 fat        0 b- stor 19-Dec-01 06:14 Slides/
-rw----     2.0 fat 31608616 bl defN 19-Dec-01 06:14 Slides/Slides.pdf
2 files, 31608616 bytes uncompressed, 30756888 bytes compressed:  2.7%

Some extraction tools ignore the 0600 (f.ex., Archive Utility on the Mac), while others take it literally (funnily enough, f.ex., Safari's "Open 'safe' files after downloading") If it is kept, file managers may prevent access, which is annoying. For example, here's a directory at 0600:

I've also reproduced the same problem when downloading the artifact on Ubuntu.

This is not related to the chmod at time of upload; for instance, I added a chmod -R 0777 to the output before uploading it, and it had no effect.

The zips should be created without capturing permissions, or at least with a permission of 0644 if it is being set somehow.

[tonyarnold]

Oh wow, this is… not good. I was using artifacts to capture an application bundle. Upon decompressing the zip, every file in the bundle has been modified to have perms of 0600.

Two things:

• There should be a documented warning somewhere with this action.
• The action shouldn't touch the permissions of the files it is archiving.

This action isn't usable for the use case of capturing executables or complex bundle structures while this limitation exists.