RFC for Microsoft.PowerShell.Archive v2.0.0

[ayousuf23]

PR Summary

This PR adds an RFC for the next version of the archive module. The RFC includes support for additional archive formats, relative path preservation, and more. The RFC addresses new features and usability enhancements for the archive module. Please read the RFC for additional details. Please offer feedback by August 6, 2022.

PR Context

The purpose of this PR is to get community feedback on the RFC.

[fflaten]

Great job on the RFC! 🙂

A few personal thoughts:

• -Update should be renamed to -Append as it won't let you remove files
• Destination folder for Expand-Archive should not be inconsistent. Unless I specify -DestinationPath, then it should always either go in a archive-named folder (default in pwsh and Windows GUI) or to the current directory (7za default I think).
  • Don't really have a preference, but I personally don't like to guess - especially when there's no cmdlet to look inside the archive.
• What about pipeline support from Get-ChildItem for advanced filtering? Ex. I often only want to compress newly updated files.
  • Supported at all? Or would we have to pre-stage files in a temp-folder to do this?
  • If supported, how would relative paths work?
  • Always flatten?
  • Keep relative paths (support -Flatten) but throw if all incoming files doesn't have a common base?

[ZanattaMichael]

Hello There! I love it! I have a few suggestions.

One of the use cases that our organization uses extensively is to be able to make changes it singular items in a zip file without having to expand and re-compress. For Example:

• Introduce an additional cmdlet, like Get-Archive, where it returns a list containing object specific information about the zip file. (ie folder structure, file's)
  • It could accept a filepath or a fileStream as input object types. (I've done work with modifying zip files in memory, so it's possible)
  • Using the object, you could add the cmdlet's Add-ArchiveItem, Remove-ArchiveItem, Update-ArchiveItem that enables you to change specific items within the zip file.

Sources: https://docs.microsoft.com/en-us/dotnet/api/system.io.compression.ziparchive?view=net-6.0

That's my two-cents. I'll head back to my corner.

[TravisEz13]

/azp list

[azure-pipelines[bot]]

CI/CD Pipelines for this repository:

• PowerShell.Microsoft.PowerShell.Archive

[TravisEz13]

/azp run PowerShell.Microsoft.PowerShell.Archive

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).

[ayousuf23]

@fflaten

Great job on the RFC! 🙂

Thanks!

A few personal thoughts:

• -Update should be renamed to -Append as it won't let you remove files

-Update also lets you replace an existing file in the archive with another file. I think -Update is more appropriate.

• Destination folder for Expand-Archive should not be inconsistent. Unless I specify -DestinationPath, then it should always either go in a archive-named folder (default in pwsh and Windows GUI) or to the current directory (7za default I think).

  • Don't really have a preference, but I personally don't like to guess - especially when there's no cmdlet to look inside the archive.

When Expand-Archive is called and -DestinationPath is not specified, if the archive has a top-level folder (and no other top-level items) then that folder is put into the current working directory. In all other cases, the contents of the archive are put into a folder with the archive's name. Do you think the cmdlet should nest the folders in the first case (i.e., create a folder with the name of the archive and put the top-level folder inside that folder)?

• What about pipeline support from Get-ChildItem for advanced filtering? Ex. I often only want to compress newly updated files.

  • Supported at all? Or would we have to pre-stage files in a temp-folder to do this?

  • If supported, how would relative paths work?

  • Always flatten?

  • Keep relative paths (support -Flatten) but throw if all incoming files doesn't have a common base?

Using Get-ChildItem is a great idea! However, Get-ChildItem outputs fully qualified paths and, in order to preserve the relative path structure, the cmdlet needs relative paths as well. We would have to reconstruct the directory structure, and this seems complicated.

[ayousuf23]

Hello There! I love it! I have a few suggestions.

One of the use cases that our organization uses extensively is to be able to make changes it singular items in a zip file without having to expand and re-compress. For Example:

• Introduce an additional cmdlet, like Get-Archive, where it returns a list containing object specific information about the zip file. (ie folder structure, file's)

  • It could accept a filepath or a fileStream as input object types. (I've done work with modifying zip files in memory, so it's possible)
  • Using the object, you could add the cmdlet's Add-ArchiveItem, Remove-ArchiveItem, Update-ArchiveItem that enables you to change specific items within the zip file.

Sources: https://docs.microsoft.com/en-us/dotnet/api/system.io.compression.ziparchive?view=net-6.0

That's my two-cents. I'll head back to my corner.

You would be able to add files to or replaces files in the archive using the -Update parameter. This sounds like a good idea. Unfortunately, due to time constraints, I am unable to add these cmdlets to v2.0.0. It could be a feature for the release after v2.0.0, and you are always welcome to submit a PR or RFC!

[fflaten]

-Update also lets you replace an existing file in the archive with another file. I think -Update is more appropriate.

Ah, I missed that. Then it makes sense. 👍

Do you think the cmdlet should nest the folders in the first case (i.e., create a folder with the name of the archive and put the top-level folder inside that folder)?

As I mentioned I don't have a preference really, but it should be consistent. Default to a archive-named folder would match current default and Windows behavior though, so probably the better way to go. 🙂

[ThomasNieto]

Why isn't this RFC in the https://github.com/PowerShell/PowerShell-RFC repo for more visibility?

[SydneyhSmith]

Why isn't this RFC in the https://github.com/PowerShell/PowerShell-RFC repo for more visibility?

This RFC is for this module rather than for PowerShell itself

[ayousuf23]

As I mentioned I don't have a preference really, but it should be consistent. Default to a archive-named folder would match current default and Windows behavior though, so probably the better way to go. 🙂

It does (as long as the archive does not have only one top-level folder and no other top-level items). There is a scenario where nesting the output of Expand-Archive can be annoying because the top-level folder has to be retrieved again and put in the working directory (this applies when there is a single top-level folder and no other top-level items).

[ThomasNieto]

Why isn't this RFC in the https://github.com/PowerShell/PowerShell-RFC repo for more visibility?

This RFC is for this module rather than for PowerShell itself

@SydneyhSmith / @SteveL-MSFT This module is shipped with PowerShell and as such should be treated the same as any other core module. The goal of a RFC is to get as many people to provide feedback as possible. There are over 100 people watching the RFC repo while this repo has 20.

[ayousuf23]

@SydneyhSmith / @SteveL-MSFT This module is shipped with PowerShell and as such should be treated the same as any other core module. The goal of a RFC is to get as many people to provide feedback as possible. There are over 100 people watching the RFC repo while this repo has 20.

Our aim is to keep RFCs for modules in their own repositories. The PowerShell-RFC repository is used for RFCs for PowerShell as a whole.

[ayousuf23]

I updated the RFC with reduced parameter sets. There is a minor change to the condition in which relative path structure preservation is done.

[jhoneill]

• -Update should be renamed to -Append as it won't let you remove files

The existing command uses -update There should be some clarity on when the command

• Creates a new archive file vs adds files to an existing one
• Replaces a file in an existing archive.

Changing -Update or Force would be a unnecessary breaking change

• Destination folder for Expand-Archive should not be inconsistent. Unless I specify -DestinationPath, then it should always either go in a archive-named folder (default in pwsh and Windows GUI) or to the current directory (7za default I think).

Whatever the current behaviour is, there will be scripts that rely on it. The problem is that we do something like <create a zip of directory foo> and the foo.zip has

-| Foo
---| File1
---| File2`

instead of

-| File1
-| File2`

So we then do <make directory FOO, change to directory foo, unzip foo .zip> and we get

-| FOO       # the directory we made  expecting files in the root of the zip to go here
---| foo       # made in the the unzip process because that is the zip file name
------| Foo  # the source directory preserved inside the zip file 
---------| File1
---------| File2`

• What about pipeline support from Get-ChildItem for advanced filtering? Ex. I often only want to compress newly updated files.

  • Supported at all?
  • Always flatten? The existing command supports Path coming from the pipeline -all the files go in the root the of the ZIP, any changes to how it works are likely to break existing scripts