1

I am implementing a tool to address software installs for Work from Home staff, and trying to download ZIP files containing either a folder that is an Autodesk "deployment" or a single EXE or MSI update file. The folder containing ZIP is unzipping fine with

[IO.Compression.ZipFile]::ExtractToDirectory($downloadFilePath, $deploymentPath)

However, the ZIP files that contain nothing but a single file are throwing

System.Management.Automation.MethodInvocationException
Exception calling "ExtractToDirectory" with "2" argument(s): "The archive entry was compressed using an unsupported compression method."

using

[IO.Compression.ZipFile]::ExtractToDirectory($downloadFilePath, $deploymentPath)

I also tried Expand-Archive -Path $downloadFilePath -DestinationPath $deploymentPath and there I get a similar error

System.Management.Automation.MethodInvocationException
Exception calling "ExtractToFile" with "3" argument(s): "The archive entry was compressed using an unsupported compression method."

But oddly, I am not using three arguments. Also note that both approaches work with the zip of a folder, while neither approach works with the zip of a file.

All ZIP files have been created with Right Click>Send to>Compressed (zipped) folder, highlighting either the deployment folder or the file to be zipped. And the problem ZIP file works fine to extract manually.

Any thoughts?

Gordon
  • 6,257
  • 6
  • 36
  • 89
  • Im unable to reproduce. Did you try using the API directly to read the file content? here is a function to simplify it https://stackoverflow.com/a/74248474/15339544 – Santiago Squarzon Nov 23 '22 at 18:55
  • @santiago-squarzon I had used `$zipContents = [System.IO.Compression.ZipFile]::OpenRead($downloadFilePath).Entries.FullName` to get a list of the paths, since I need to handle folder zip differently from file zip after the unzip process. That seems to be working right for both conditions, so what should I be looking for with the other approach? – Gordon Nov 23 '22 at 19:00
  • 1
    How were the files compressed? Could be Deflate64 which is proprietary. What .Net Framework are you on? – Abraham Zinala Nov 23 '22 at 19:02
  • Have you tried extracting the entries manually ? with `CopyTo` from wrapped stream to file stream ? – Santiago Squarzon Nov 23 '22 at 19:03
  • Everything created with Right Click Send to Compressed archive. On the same Win 10 VM that I am running the Unzip script on. @santiago-squarzon I can extract manually, no problem. Not sure about extracting with streams. Will need to look into how that's done. I just find it super odd that a folder works, but a file doesn't. – Gordon Nov 23 '22 at 19:31
  • Curiouser and curiouser. I tried putting the file in a folder, and zipping that. Same failure. The file being zipped is an Autodesk update EXE, and I wonder if there is something about the encryption of that file? Still, makes the ZIP functionality off windows pretty @$#ing useless if I can't zip a file that contains other zipped stuff. Super weird. – Gordon Nov 23 '22 at 19:45
  • If `[IO.Compression.ZipFile]::ExtractToDirectory( )` failed then there is something off with your zip.. I can post showing how to extract manually using the API but that will likely fail too – Santiago Squarzon Nov 23 '22 at 19:46
  • But, I can manually unzip my zip, it ONLY fails in Powershell. Which is odd. But I was about to say I had used the EXE to do an update, and I realized I had not yet tested this newest update. I have two earlier updates, that I have tested, and I have been using those to test downloading the update EXE directly (since there isn't that much space saving between the EXE and the ZIP of the EXE. So, testing the EXE itself now. Would be interesting if somehow the unzip process in PS is "seeing" a corrupt update.exe. – Gordon Nov 23 '22 at 20:07
  • Maybe its worth giving `CopyTo` from wrapped stream to file stream a try but Im not sure that will work if both .NET and cmdlet already failed. Basically you need to open the zip archive and enumerate all entries, for each entry call `.Open()` to get the wrapped stream, them `.CopyTo` to a file stream you have created beforehand – Santiago Squarzon Nov 23 '22 at 21:17
  • 1
    @Gordon, do you still need a solution? I recently worked on [unzipping a text file into memory](https://stackoverflow.com/a/74332967/4190564). Initially I tried `using namespace System.IO.Compression`, but that failed. Wound up using 7-Zip's `7z.dll` from PowerShell. If it is a valid zip file, there should be a way to use 7-Zip from PowerShell to get the job done. – Darin Nov 24 '22 at 05:09
  • I am still looking for a solution, but I am also finding more issues. I verified that the EXE is good. And I also tried zipping some other files, and those unzip processes fail as well. So then I though maybe I need to zip with PowerShell too, and two weird things happened. 1: Hoe the heck to you zip JUST a file when `[IO.Compression.ZipFile]::CreateFromDirectory()` is the only option, and doesn't work with a file? And two, when I copied one of the ZIP files that was failing in the other code, and unzipped in some test code. IT FLIPPIN WORKED. Ugh. – Gordon Nov 24 '22 at 13:36
  • But, more interesting. I copied that file off my NAS, so the code was copying from a virtual network path, that is really my VM Host. That works. But when the code copies from the NAS, I still see the failure. So it's like either Copy-Item from the NAS causes corruption somehow, or isn't really complete. But again, weird that I have no issues when the ZIP is 100 times as big, still on the NAS, but a ZIP of a folder. So frustrating, but par for the course with Microsoft. – Gordon Nov 24 '22 at 14:46

0 Answers0