Microsoft.PowerShell.Archive
Microsoft.PowerShell.Archive copied to clipboard
Compress-Archive is stripping UNIX file permissions
Related ticket: https://github.com/PowerShell/PowerShell/issues/3590
Steps to reproduce
Set-Content -Path mytestfile.txt -Value testing
Compress-Archive -Path mytestfile.txt -Destination mytestzip.zip
zipinfo mytestzip.zip
Result of zipinfo command
Archive: mytestzip.zip
Zip file size: 136 bytes, number of entries: 1
?--------- 2.0 unx 8 b- defN 17-Apr-18 12:23 mytestfile.txt
1 file, 8 bytes uncompressed, 10 bytes compressed: -25.0%
Expected behavior
Permissions of files are retained upon compression into ZIP format.
Actual behavior
Permissions are not preserved when files are compressed.
Environment data
Name Value
---- -----
PSVersion 6.0.0-alpha
PSEdition Core
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 3.0.0.0
GitCommitId v6.0.0-alpha.18
CLRVersion
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
PS /> uname -a
Darwin 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar 3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64
Cheers, Trevor Sullivan
Just got bitten by this.
Have similar issue. After decompressing of archive created by Compress-Archive
in pwsh a directory from archive has empty flags and it is not allowed enter there.
I'm running into this issue, does anyone have a solution?
I'm running into this issue with Expand-Archive
. I know that the archive was created with the permissions in place and other unarchivers extract it with the right permissions, but PowerShell's Expand-Archive
doesn't extract the files with any permissions.
After trying to roll my own permissions updater in Python and Bash, I give up. It doesn't matter what the permissions for the file are before the Compress-Archive
cmdlet is, the result is always the same as described in the OP.
Steps to re-create the container I'm running it in:
FROM openshift/jenkins-slave-maven-centos7:latest
...
curl https://packages.microsoft.com/config/rhel/7/prod.repo | tee /etc/yum.repos.d/microsoft.repo \
yum install -y powershell
...
bash-4.2$ pwsh -version
PowerShell 7.1.0
bash-4.2$ uname -a
Linux 37d8d15bcd70 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
The Python script I tried rolling vaguely looks like this:
subprocess.call(['chmod', '0755', path])
for root, dirs, files in os.walk(path):
for d in dirs:
os.chmod(os.path.join(root, d), 0o755)
for f in files:
os.chmod(os.path.join(root, f), 0o755)
Good luck to those who venture further, I think the easiest way forward is to fix the cmdlet or run Powershell on native Windows.
Got bitten by this as well. 😂
I'm also encountering this issue - using PowerShell to zip up and update AWS lambda function (python) from macOS. Would like to continue using PowerShell for this, but I have no option to adjust file permissions after the file is unzipped.
Got bitten by the same bug running PS 7.0.3 any fixes out there ?
GitCommitId 7.0.3 OS Darwin 19.6.0 Darwin Kernel Version 19.6.0: Thu May 6 00:48:39 PDT 2021; root:xnu-6153.141.33~1/RELEASE_X86_64
@b-olesen I moved my builds/deploys from windows to linux, partly because of this issue. I did temporarly pull down AWS toolkit and extract a tool from their code to do the zipping as a .net core cli tool which worked, but it was such a pain to setup.
As far as I'm concerned zipping via powershell is broken, and I'm too dumb to know how to fix it to ty contribute back :(
faced the same issue while deploying the Zip created using Compress-Archive on Azure App Service (Linux). The service fails to start by throwing realpath(my.dll) failed: Input/output error
when running startup command dotnet my.dll
, upon listing the files in extracted folder we found the permissions were missing. So we ended up using linux zip command instead of PS core Compress-Archive. It would be nice if Compress-Archive also supports retaining permissions.
Any tentative timelines to fix this ?
Currently this is not possible due to .NET API limitations.
@ayousuf23 Any ETA on when the ,net API limitations will be addressed ?
@ayousuf23 Any ETA on when the ,net API limitations will be addressed ?
If they haven't been in .NET 7, I would imagine it wouldn't be until at least November when .NET 8 releases.
I think this may be possible in .NET 7? Couldn't FileSystemInfo.UnixFileMode be used to populate the ZipArchiveEntry.ExternalAttributes?
It's worth noting that from pwsh 7.3, when this started being build for .NET 7, I think Compress-Archive should have started applying some default permissions (defined here), and that does seem to have been my experience, tested in WSL2.