Compress-Archive -Update deletes the destination if the source directory is empty.

[dantraMSFT]

Repro:
Create two directories; populate the first directory (c:\FolderA) with one or more files and leave the second directory (c:\FolderB) empty.

Step 1: Create the initial zip file using FolderA
Compress-Archive -Path c:\FolderA -DestinationPath .\myfolders.zip

Step 2: Update the zip file with FolderB
Compress-Archive -Path c:\FolderB -DestinationPath .\myfolders.zip

Expected: The target zip file is created as step 1 and not updated as step 2
Actual: The target zip file is deleted in step 2 due to FolderB being empty.

Module Information:
ModuleType Version Name ExportedCommands

---

Manifest 1.1.0.0 Microsoft.PowerShell.Archive {Compress-Archive, Expand-Archive}

PSVersionTable
Name Value

---

PSVersion 6.0.0-beta
PSEdition Core
GitCommitId v6.0.0-beta.5-34-g1a8563336a1a7f297c05fe06d732994f8efa8691
OS Microsoft Windows 10.0.16262
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

[AlexBillon07]

Same problem on Powershell 5.1

Name Value

---

PSVersion 5.1.14409.1012
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14409.1012
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

[bchris999]

Same issue for me. Been open for over a year now.

[stummsft]

When using Update, the target archive also gets deleted when one of:

1. All of the path elements provided are unsuccessful.
2. Any file access error occurs after any previous provided path has been successful (when multiple paths are provided in an array)
3. When only one path element is provided and there is a file access error opening it (as a consequence of issues 2 and 1 combining)

To the first issue, a path will be unsuccessful if:

1. It is an empty directory
2. It is a shell glob that does not resolve to a real file or non-empty directory
3. A file access error occurs: statically inaccessible due to permissions or runtime inaccessible due to being in use by another process. There may be other possibilities.

To the second issue, if the file is statically inaccessible due to user permissions or is in use by another process, an exception of CompressArchiveUnauthorizedAccessError will be raised at line 632 but then the constructor at line 808 for System.IO.BinaryReader will raise a "Stream was not readable." exception. This seems to be a stale initialization issue with $currentFileStream because the assignment at 790 never occurs due to the exception raised inside of System.IO.File::Open(). I can put in a tiny PR for it (#80 ) as it's a one-line fix.

If any provided path succeeds, the destination zip's contents will be preserved unless the access issue is triggered. If the access issue is triggered, all prior zip contents will be deleted and none will be added even if a later Path array entry would be successful.
I as yet have not been able to determine why the destination file gets deleted when one of these issues is triggered.

[bachittle]

good old powershell still has this bug. Might as well use 7-Zip or WinRAR at this point....

[ayousuf23]

This has been fixed.