[Bug] Expand-7zipArchive won't remove top folder if $ExtractDir depth exceeds 2

[z-Fng]

Bug Report

Related Issues/PRs

• Relates to #6092. https://github.com/ScoopInstaller/Scoop/blob/b588a06e41d920d2123ec70aee682bae14935939/lib/decompress.ps1#L128-L130

Current Behavior

When the $ExtractDir depth exceeds 2, like keep\sub\sub-sub, top folder keep will not be removed.

The return value of Get-ChildItem for top folder 'keep' is always greater than 0 as there exists a 'sub' folder.

└─ keep
   └─ sub
      └─  sub-sub
         └─  empty
   └─ othersub

Example

Search bucket using the regular expression extract_dir.*(/|\\\\).*(/|\\\\).*.

amber.json

Possible Solution

Perhaps we could check if the folder exists recursively before 7-Zip actually starts extracting?

keep
   └─ sub
      └─  sub-sub

1. Check if the folder $DestinationPath\keep exists.
   • If it does not exist, we can safely remove $DestinationPath\keep.
   • If it does exist, proceed to step 2.
2. Check if the folder $DestinationPath\keep\sub exists.
   • If it does not exist, we can safely remove $DestinationPath\keep\sub.
   • If it does exist, proceed to step 3.
3. ...

[o-l-a-v]

~~Note to whoever tries to solve this:~~

~~The example manifest has it's own cleanup step in the installer script that makes this issue not appear. If commenting it out ( https://github.com/ScoopInstaller/Extras/blob/845eb91b97953483194d6417f23cafd156b59930/bucket/foxit-reader.json#L30 ), the msi directory is left behind.~~

Edit: I still don't get how this is a bug/issue with Expand-7zipArchive. 🤔 It does not leave behind any unexpected directories as far as I can see.

Can we find a manifest that actually shows the issue? Or create one? It would be beneficial for automated testing on PRs as well, to make sure it does not regress in the future.

• https://github.com/ScoopInstaller/Scoop/blob/master/test/Scoop-Decompress.Tests.ps1
• https://github.com/ScoopInstaller/Scoop/blob/master/test/fixtures/decompress/TestCases.zip

[z-Fng]

It does not leave behind any unexpected directories as far as I can see.

It doesn't cause much trouble, just leaves an empty top folder behind. Guess we can still call it a bug?

Can we find a manifest that actually shows the issue?

Not many, but you can still find some in Extras bucket by searching with regex extract_dir.*(/|\\\\).*(/|\\\\).*, e.g. amber Top folder: target. Updated in the description.

It would be beneficial for automated testing on PRs as well, to make sure it does not regress in the future.

Yes, it makes sense. We can add it later.