RFC for Microsoft.PowerShell.Archive v2.0.0 #117

ayousuf23 · 2022-07-06T17:33:33Z

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.

rfc/RFCNNNN-Archive-Module-v2.md

updated spelling of a word Co-authored-by: Flavien <fmichaleczek@gmail.com>

fflaten · 2022-07-06T20:09:54Z

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 · 2022-07-07T07:18:29Z

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 · 2022-07-07T21:39:03Z

/azp list

azure-pipelines · 2022-07-07T21:39:08Z

CI/CD Pipelines for this repository: PowerShell.Microsoft.PowerShell.Archive

TravisEz13 · 2022-07-07T21:39:37Z

/azp run PowerShell.Microsoft.PowerShell.Archive

azure-pipelines · 2022-07-07T21:39:46Z

Azure Pipelines successfully started running 1 pipeline(s).

rfc/RFCNNNN-Archive-Module-v2.md

Co-authored-by: Steve Lee <slee@microsoft.com>

ayousuf23 · 2022-07-14T17:26:41Z

@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 · 2022-07-14T17:32:42Z

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 · 2022-07-14T17:32:57Z

-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 · 2022-07-14T20:45:17Z

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

ThomasNieto · 2022-07-15T20:54:15Z

rfc/RFCNNNN-Archive-Module-v2.md

+Compress-Archive [-Path] <string[]> [-DestinationPath] <string> [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]
+
+Compress-Archive [-Path] <string[]> [-DestinationPath] <string> -Overwrite [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]
+
+Compress-Archive [-Path] <string[]> [-DestinationPath] <string> -Update [-CompressionLevel {Optimal |NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]
+
+Compress-Archive [-DestinationPath] <string> -LiteralPath <string[]> [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]
+
+Compress-Archive [-DestinationPath] <string> -LiteralPath <string[]> -Overwrite [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]
+
+Compress-Archive [-DestinationPath] <string> -LiteralPath <string[]> -Update [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]


Suggested change

Compress-Archive [-Path] <string[]> [-DestinationPath] <string> [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]

Compress-Archive [-Path] <string[]> [-DestinationPath] <string> -Overwrite [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]

Compress-Archive [-Path] <string[]> [-DestinationPath] <string> -Update [-CompressionLevel {Optimal |NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]

Compress-Archive [-DestinationPath] <string> -LiteralPath <string[]> [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]

Compress-Archive [-DestinationPath] <string> -LiteralPath <string[]> -Overwrite [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]

Compress-Archive [-DestinationPath] <string> -LiteralPath <string[]> -Update [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]

Compress-Archive [-Path] <string[]> [-Destination] <string> [-Collision {NoClobber, Overwrite, Update } [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]

Compress-Archive [-LiteralPath] <string[]> [-Destination] <string> [-Collision {NoClobber, Overwrite, Update} [-CompressionLevel {Optimal | NoCompression | Fastest | SmallestSize}] [-PassThru] [-Format {zip | tar | tgz}] [-Filter <string[]>] [-Flatten] [-WhatIf] [-Confirm] [<CommonParameters>]

There are way to many parameter sets to be user friendly and the only difference is -Update and -Overwrite switch parameters. These two switch parameters change the collision behavior when the destination already exists.

Only two parameter sets are needed -Path and -LiteralPath

-Overwrite and -Update parameters replaced with an enum parameter -Collision { NoClobber, Overwrite, Update }. NoCobber would be the default value and have the behavior described in the RFC when Update or Overwrite is not specified. Update and Overwrite would have the behavior described in the RFC.

Parameter -DestinationPath should be renamed to -Destination to match core cmdlets like Copy-Item and Move-Item. A DestinationPath alias can be added for backwards compatibility.

Parameter -LiteralPath should have Position = 0

Parameter -Destination should have Position = 1

I agree about the number of parameter sets. I think -Collision can be confusing to users because collision could refer to destination file collision or archive entry collision. I propose -WriteMode { Create, Update, Overwrite} as an alternative.

Parameter -DestinationPath should be renamed to -Destination to match core cmdlets like Copy-Item and Move-Item. > A DestinationPath alias can be added for backwards compatibility.

How do you feel about keeping -DestinationPath and using -Destination as an alias?

Parameter -LiteralPath should have Position = 0
Parameter -Destination should have Position = 1

Since -Path has position 0, -LiteralPath cannot have position = 0. I agree with putting -DestinationPath after -LiteralPath.

The existing function uses DestinationPath. So that must be a name or an alias or existing scripts will break .
-Destination is unambiguous as an abbreviation so there is no need to add it as an alias.

The existing function has Path as position 0 allowing compress-archive *.ps1
Swapping path and literalpath would break existing scripts which don't formally write -path (and there will be many)

Adding complexity with more parameter sets should be avoided but fixing decisions made in the original model will usually do more harm than good

By the same logic existing scripts use -Force and -Update. Breaking these won't be acceptable
That does result in sets for Path or LiteralPath x update or force .

I updated the parameter sets. The position of -LiteralPath is changed so that it now comes before -DestinationPath. Also, the number of parameter sets is reduced.

ThomasNieto · 2022-07-15T20:59:06Z

rfc/RFCNNNN-Archive-Module-v2.md

+Expand-Archive [-Path] <string> [[-DestinationPath] <string>] [-Overwrite] [-PassThru] [-Filter <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]
+
+Expand-Archive [[-DestinationPath] <string>] -LiteralPath <string> [-Overwrite] [-PassThru] [-Filter <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]


Suggested change

Expand-Archive [-Path] <string> [[-DestinationPath] <string>] [-Overwrite] [-PassThru] [-Filter <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

Expand-Archive [[-DestinationPath] <string>] -LiteralPath <string> [-Overwrite] [-PassThru] [-Filter <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

Expand-Archive [-Path] <string> [[-Destination] <string>] [-Overwrite] [-PassThru] [-Filter <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

Expand-Archive [-LiteralPath] <string> [[-Destination] <string>] [-Overwrite] [-PassThru] [-Filter <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

Parameter -DestinationPath should be renamed to -Destination to match core cmdlets like Copy-Item and Move-Item. A DestinationPath alias can be added for backwards compatibility.

Parameter -LiteralPath should have Position = 0

Parameter -Destination should have Position = 1

Parameter -Overwrite should be named -Force to match core cmdlets or if that is unacceptable a Force parameter alias added.

Parameter -DestinationPath should be renamed to -Destination to match core cmdlets like Copy-Item and Move-Item. A DestinationPath alias can be added for backwards compatibility.
Parameter -LiteralPath should have Position = 0
Parameter -Destination should have Position = 1

See my comment above.

Parameter -Overwrite should be named -Force to match core cmdlets or if that is unacceptable a Force parameter alias added.

PowerShell is moving away from -Force because it is vague. -Overwrite is more specific and preferred.

@ayousuf23 the only time Force is an issue is when it's not instantly clear what it will do and if it does more than one thing. In this case that is neither the concern or issue. Install-Module is the perfect example of bad Force design where it does too many things, reinstalls the module, disables certain checks, and suppresses prompts. PowerShell design works best when the commands are consistent. Force has been used since the beginning and does have some issues like I described above but if the user has been using PowerShell for any length of time, they will first try Force. As such if the PowerShell team is unwilling to change the name then be nice to your long time users by adding a Force alias.

P.S. None of the current built-in commands have Overwrite as a parameter or alias. There is however, a NoOverwrite alias for a few NoClobber parameters. I'd recommend the team add Overwrite aliases to existing Force parameters where it makes sense to be more consistent if Overwrite will be the new standard parameter for this behavior.

@ayousuf23 Although there may be a desire to reduce the use of the -Force switch, it is well understood (don't confirm, do overwrite) and is embedded in many existing scripts.

The way to resolve the conflict between compatibility and fixing things which the original design didn't get quite right would be to use new command names.
We don't take an archive and compress it. Really the command should be New-Archive, and have Add-ArchiveFile, Remove-ArchiveFile and Update-ArchiveFile commands for changing an existing file and Show-ArchiveFile for listing its contents.
Expand doesn't allow a subset of files to be extracted, copy-archiveFile would be ideal for that task but I'm not sure if that is as good a name for the common use of expand everything, but (again) changing the name sidesteps the problem of breaking existing scripts.

The way to resolve the conflict between compatibility and fixing things which the original design didn't get quite right would be to use new command names.

Good idea!

We don't take an archive and compress it. Really the command should be New-Archive, and have Add-ArchiveFile, Remove-ArchiveFile and Update-ArchiveFile commands for changing an existing file and Show-ArchiveFile for listing its contents.

This is an interesting idea. I need to think about it some more before I get back to you.

Expand doesn't allow a subset of files to be extracted, copy-archiveFile would be ideal for that task but I'm not sure if that is as good a name for the common use of expand everything, but (again) changing the name sidesteps the problem of breaking existing scripts.

We can add a parameter to Expand-Archive that allows a subset of files to be extracted. This way it won't break existing scripts and it can still be used.

I'd rather this module keep using -Force for compatibility's sake.

SydneyhSmith · 2022-07-18T21:44:00Z

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 · 2022-07-18T22:23:01Z

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 · 2022-07-18T23:09:04Z

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.

jhoneill · 2022-07-20T17:13:46Z

rfc/RFCNNNN-Archive-Module-v2.md

+
+Second, the module has limited performance compared to other archive software.
+Writing the next version of the module in C# instead of PowerShell Script is expected to improve the overall performance of the module.
+The module has limited cross-platform support because archive entries are written in an OS-specifc way due to different characters being used as path seperators in different OSs.


I think we should pivot what is being said here.

There is new support in .NET for file types other than ZIP.

Updating the PowerShell functionality to use the new functionality in .NET there provides as chance to address some existing problems.

Performance is dictated by .NET - although calling from C# will reduce some of the overhead the time to do the compression or expansion is not going to change. If .NET's implementation is slower than 7Zip's , PowerShell won't fix that

Supported formats are dictated by .NET, the goal should be to support any format supported by .NET but not to add formats.

Where .NET offers options (like compression levels) and it makes sense to support them, the module should do so, but it shouldn't be a goal to support everything, nor to go above and beyond the options .NET exposes

If the new module is bundled with PowerShell it is imperative that the module does not hinder the adoption of newer versions of PowerShell by breaking existing scripts

Conversely if it fixes issues with wildcards (beyond users not knowing they need to use -literalpath) and improves compatibility it helps adoption of newer versions.

I updated the description based on your feedback.

jhoneill · 2022-07-20T17:38:37Z

rfc/RFCNNNN-Archive-Module-v2.md

+```
+
+The archive preserves the relative structure of the input path.
+


This will break existing scripts, which allow an absolute a relative path to be specified and will only create the MyFolder folder in the Zip file.

At present Compress-Archive -Path MyGrandparentFolder/MyParentFolder/MyFolder treats MyFolder as the item to be compressed and creates a top level folder in the ZIP file,
but Compress-Archive -Path MyGrandparentFolder/MyParentFolder/MyFolder/*.* puts the items in MyFolder at the top level of the zip.

Preserving the intermediate levels is useful, but should not be the default and should be enabled by a switch.

jhoneill · 2022-07-20T17:40:14Z

rfc/RFCNNNN-Archive-Module-v2.md

+A zip archive is created with the name `destination.zip`.
+The archive contains all the files in or descendents of MyFolder.
+The archive **does not** retain the directory structure since `-Flatten` is specified.
+


-Flatten implies all the files are in the same folder.
Is this actually intended as a DoNotBreakExistingScripts switch ?

No, it is not intended as a switch that maintains backwards compatibility.

jhoneill · 2022-07-20T18:06:51Z

rfc/RFCNNNN-Archive-Module-v2.md

+#### **Relative Path Structure Preservation**
+
+When valid path(s) is supplied to the `-Path` or `-LiteralPath` parameter, the relative structure of the path is preserved as long as the path is not absolute, and does not contain ~ or .. (the path can contain other wildcard characters such as *, [, ], ?, and `).
+


See above that preserving the path will be a breaking change for existing scripts
In a PATH parameter File[12] means File1 or File2 in a literal path [12] is allowed to mean the twelfth file of a a set. It is important that users can still use (e.g) "Log[0-9]*.txt" to include files with "log" a digit and anything else. but exclude "Logarithms.txt" - I think this probably understood, but it does not come through reading the text.

The -LiteralPath parameter behaves the same as before in regard to interpreting wildcard characters literally (i.e., not expanding wildcard characters).

jhoneill · 2022-07-20T18:07:03Z

rfc/RFCNNNN-Archive-Module-v2.md

+```
+
+A zip archive is created with the name `destination.zip`.
+Notice the cmdlet sees the `.zip` extension and uses the `zip` format.


Will this apply to the other file extensions ? If -format is only required when NOT using a standard extension that is a bonus.

-Format is an option parameter. If -DestinationPath has an extension that matches a supported format (e.g., .zip, or .tar), then the cmdlet will determine the archive as the format that matches the extension.

jhoneill · 2022-07-20T18:07:18Z

rfc/RFCNNNN-Archive-Module-v2.md

+    As a PowerShell user,
+    I can expand archives quickly and compress files and folders quickly,
+    so that I can reduce the cost of operating my server.
+


I would drop this last point, as performance is not under the control of the module. Costs are only reduced by having fewer servers, or fewer people, and it's hard to see that faster compression would reduce head count or machine count.

I updated this point.

ayousuf23 · 2022-07-20T21:43:10Z

@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.

… preservation

…ve into rfc

ayousuf23 · 2022-07-20T23:46:02Z

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 · 2022-07-21T09:09:17Z

-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

jhoneill · 2022-07-21T09:26:45Z

rfc/RFCNNNN-Archive-Module-v2.md

@@ -256,7 +250,7 @@ Note that the `Documents` folder is not retained in the archive.

 Example: `Compress-Archive -Path Documents -DestinationPath destination.zip -Flatten` creates an archive which only contains the files in or descended from `Documents` and these files are the top-level items.

-The `-Flatten` parameter can be used with `-Update`.
+The `-Flatten` parameter can be used with `-WriteMode Update`.


-Update is used in existing scripts, so is needed to avoid breaking them.

-Writemode is better , so the code needs to have an Update switch with the DontShow flag set, and if specified this will set the value Writemode.

The same goes with -Force to avoid a breaking change a hidden force parameter that sets WriteMode to Overwrite.

jhoneill · 2022-07-21T09:33:33Z

rfc/RFCNNNN-Archive-Module-v2.md

+    As a PowerShell user,
+    I can expand archives quickly and compress files and folders quickly,
+    so that I can reduce the cost of operating my server.
+


There is a design flaw with Zip which goes back to its origins on MS DOS. It stores the date/time as displayed - i.e. as local time, not UTC time. And when the file is extracted the time is set as local time. This means if compress and expand happen on machines with different time zone settings the time stamp on the files changes. Changing the file format to fix this is absolutely out of scope, however a -SourceTimeZone parameter could allow the unzip operation to create correctly dated files.

The problem with -SourceTimeZone is that it seems like it is only needed for Zip and not other archive formats. How can we make this work for other formats as well?

If other formats store the as "wall time time with the offset from utc" - equivalent to Get-Date -Format "o" or always use the same timezone (UTC , Pacific, whatever), then the best course is either to show a warning and ignore any time adjustment parameter, or possibly to apply it only if a -Force or a similar switch is used. Zip has never become time zone aware, because either it would mean new files couldn't be unzipped by old programs, or files would get different dates depending on which version unzipped them.

Applying a fixed offset to all files doesn't work, because daylight savings time moves the clock in opposite directions in the Northern and Southern Hemisphere and is applied at different dates. .NET timezones are smart enough to know that what offset applies in particular timezone at a given time. (I wrote about it :-) https://jhoneill.github.io/2022/03/07/Timezones.html )

This is a good idea. I think we can keep this on the backlog and add this feature as time permits.

added rfc

f4ca331

fMichaleczek reviewed Jul 6, 2022

View reviewed changes

rfc/RFCNNNN-Archive-Module-v2.md Outdated Show resolved Hide resolved

Update rfc/RFCNNNN-Archive-Module-v2.md

b3faf00

updated spelling of a word Co-authored-by: Flavien <fmichaleczek@gmail.com>

SteveL-MSFT reviewed Jul 7, 2022

View reviewed changes

rfc/RFCNNNN-Archive-Module-v2.md Outdated Show resolved Hide resolved

fixed typo in RFC

5cfe423

Co-authored-by: Steve Lee <slee@microsoft.com>

ThomasNieto reviewed Jul 15, 2022

View reviewed changes

jhoneill reviewed Jul 20, 2022

View reviewed changes

Abdullah Yousuf added 3 commits July 20, 2022 16:42

modified RFC, updated parameter sets, updated relative path structure…

1f3ee10

… preservation

Merge branch 'rfc' of github.com:ayousuf23/Microsoft.PowerShell.Archi…

cc4d45c

…ve into rfc

minor formatting update

d21e4ae

jhoneill reviewed Jul 21, 2022

View reviewed changes

updated RFC description

5290691

ayousuf23 mentioned this pull request Jul 28, 2022

Archive module preview 1 PR #131

Merged

ayousuf23 mentioned this pull request Aug 9, 2022

Archive module preview 2 & 3 #138

Merged

ayousuf23 added 2 commits August 11, 2022 15:07

updated section on relative path structure preservation

5bd0b4d

updated parameter sets, section for filtering an archive

dcf7716

		Expand-Archive [-Path] <string> [[-DestinationPath] <string>] [-Overwrite] [-PassThru] [-Filter <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

		Expand-Archive [[-DestinationPath] <string>] -LiteralPath <string> [-Overwrite] [-PassThru] [-Filter <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

		```

		The archive preserves the relative structure of the input path.

		#### Relative Path Structure Preservation

		When valid path(s) is supplied to the `-Path` or `-LiteralPath` parameter, the relative structure of the path is preserved as long as the path is not absolute, and does not contain ~ or .. (the path can contain other wildcard characters such as *, [, ], ?, and `).

RFC for Microsoft.PowerShell.Archive v2.0.0 #117

Are you sure you want to change the base?

RFC for Microsoft.PowerShell.Archive v2.0.0 #117

Conversation

ayousuf23 commented Jul 6, 2022 • edited Loading

PR Summary

PR Context

fflaten commented Jul 6, 2022

ZanattaMichael commented Jul 7, 2022

TravisEz13 commented Jul 7, 2022

azure-pipelines bot commented Jul 7, 2022

TravisEz13 commented Jul 7, 2022

azure-pipelines bot commented Jul 7, 2022

ayousuf23 commented Jul 14, 2022

ayousuf23 commented Jul 14, 2022

fflaten commented Jul 14, 2022

ThomasNieto commented Jul 14, 2022

ThomasNieto Jul 15, 2022 • edited Loading

Choose a reason for hiding this comment

ayousuf23 Jul 18, 2022 • edited Loading

Choose a reason for hiding this comment

jhoneill Jul 19, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ayousuf23 Jul 18, 2022 • edited Loading

Choose a reason for hiding this comment

ThomasNieto Jul 18, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SydneyhSmith commented Jul 18, 2022

ayousuf23 commented Jul 18, 2022

ThomasNieto commented Jul 18, 2022

jhoneill Jul 20, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ayousuf23 commented Jul 20, 2022

ayousuf23 commented Jul 20, 2022

jhoneill commented Jul 21, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ayousuf23 commented Jul 6, 2022 •

edited

Loading

ThomasNieto Jul 15, 2022 •

edited

Loading

ayousuf23 Jul 18, 2022 •

edited

Loading

jhoneill Jul 19, 2022 •

edited

Loading

ayousuf23 Jul 18, 2022 •

edited

Loading

ThomasNieto Jul 18, 2022 •

edited

Loading

jhoneill Jul 20, 2022 •

edited

Loading

jhoneill commented Jul 21, 2022 •

edited

Loading