Jeff Hicks over at The Lonely Administrator recently pointed out one of his older blog posts on the topic of compressing a file. This has always struck me as one of the odd gaps in PowerShell’s core capabilities. There are so many ways to accomplish it yet no one at Microsoft thought to include that with PowerShell. The thing that always struck me as odd was that Microsoft identifies ‘Compress’ as a valid verb in their MSDN documentation, however no such cmdlet ships in PowerShell core with that verb.

What I found interesting about Jeff’s post was that I learned yet another way to compress a file. His code utilized the compress method on the WMI CIM_DATAFILE class. I did it for years using “Shell. Application”. I ended up writing this one to use .NET, System.IO.Compression.GzipStream. I’ve added to it and cleaned it up over time. With the current gap in PowerShell core it’s defiantly one of my go to cmdlet/functions. Seeing Jeff’s post prompted me to dig it out and post it up here.

Here is the complete function with embed help and everything.

CompressFile.ps1

I’ll break it down below.

Function Compress-JRFile {
[CmdletBinding()]
Param(
    [Parameter(Position=0,ValueFromPipelineByPropertyName=$true,Mandatory=$True)]
    [Alias("FullName")]
    [string]$InputFile,
    [string]$OutputPath,
    [string]$CompressExtension = ".zip",
    [switch]$Delete
)

The usual CmdletBinding for advanced functions. The basic parameters are: InputFile, what you want to compress; OutputPath, put compressed file somewhere other then next to input. I also created parameters for your choice of extension, and whether to delete the original.

$InputFile = (Resolve-Path -Path $InputFile).Path            

If ($OutputPath -eq "")
{
    $OutputFile = [IO.Path]::ChangeExtension($InputFile,$CompressExtension)
}
Else
{
    $CompletePath = Join-Path -Path ($(Resolve-Path -Path $OutputPath).Path) -ChildPath ((Get-ItemProperty -Path $InputFile).Name)
    $OutputFile = [IO.Path]::ChangeExtension($CompletePath,$CompressExtension)
}

I resolve and prepare all of the input and output paths, whether or not they are relative, as well as handling whether or not the OutputPath parameter is specified or not.

Try
{
    $SourceFile = New-Object System.IO.FileStream $InputFile, ([IO.FileMode]::Open), ([IO.FileAccess]::Read), ([IO.FileShare]::Read)
    $SourceFileSize = $(Get-ItemProperty -Path $InputFile).Length
}
Catch [System.IO.IOException]
{
    Throw "Unable to access $InputFile"
    Exit
}            

$SourceBuffer = New-Object byte[]($SourceFile.Length)
$SourceBytes = $SourceFile.Read($SourceBuffer,0,$SourceFile.Length)
$SourceFile.Close()

I move on to prepping the source file. I have used this cmdlet for predominately large IIS log files. In an early version of this cmdlet I used Get-Content to initially read the file in, however I learned that Get-Content doesn’t operate very well on large files. So I just switched over to reading the file using .NET. I also have my Try/Catch in place with a Throw in case the files are unreadable for some reason. I think this might be a place I could improve it. I don’t think I’ve ever expressly tested or even encountered the Catch in real world usage. Not sure if I could or should be doing something differently here.

Try
{
    $GzipFile = New-Object System.IO.FileStream $OutputFile, ([IO.FileMode]::Create), ([IO.FileAccess]::Write), ([IO.FileShare]::None)
}
Catch [System.IO.IOException]
{
    Throw "Unable to create $OutputFile"
    Exit
}            

$GzipStream = New-Object System.IO.Compression.GzipStream $GzipFile, ([IO.Compression.CompressionMode]::Compress)
$GzipStream.Write($SourceBuffer, 0, $SourceBuffer.Length)
$GzipStream.Close()
$GzipFile.Close()            

$GzipFileSize = $(Get-ItemProperty -Path $OutputFile).Length

The actual writing of the compression stream is pretty similar to the reading portion as far as the Try/Catch/Throw goes. Most of the .NET was taken was from examples I found from MSDN and elsewhere. I’m not expressly a programmer by trade or training. I have found I have learned a fair bit of C# and .NET while attempting to develop and solve my more atypical PowerShell problems.

If($Delete)
{
    Remove-Item -Path $InputFile
    $IsDeleted = $true
}
Else
{
    $IsDeleted = $false
}            

$ObjectProperties = @{ "SourceFile" = $InputFile;
                       "SourceSize" = $SourceFileSize;
                       "OutputFile" = $OutputFile;
                       "OutputSize" = $GzipFileSize;
                       "SourceFileDeleted" = $IsDeleted;
                       "CompressionRatio" = [int]$(($GzipFileSize / $SourceFileSize) * 100 )
                     }            

$Object = New-Object -Type PSObject -Property $ObjectProperties            

Write-Output $Object
}

Mostly the tail end of a typical advanced function, and what makes PowerShell uniquely PowerShell. I handle my Delete parameter and do the needful. Lastly I create a hashtable with all the properties that I intend to send along with my object. I’ve seen so much great (and no so great) PowerShell code over the years but so many people go to all the trouble of writing their code to solve their problems and then shot themselves in the foot by not outputting a simple object to close out their code (ideally a function).

I tend to capture and output anything that I might need now or in the future so I have it. You could probably get carried away but I have found most of what I output useful over time. One thing on my to-do list with this and my stable of other cmdlet/functions is prepare format.ps1xml files for my custom functions. This way they would look a little prettier in the shell. I would need to modify the $Object further before sending it along to make this work. To this point I mostly just use Select-Object to filter out what I’m really after or just don’t care because I never see it on its way to some other cmdlet.

Well hopefully I can retire this someday when Microsoft adds this functionality to the PowerShell core. Until then I’ll happily continue to use this one, as well as my other gap fillers. The nice thing about a properly built PowerShell advanced function is that anyone with basic PowerShell skills can use your cmdlet and never need to have the programming skills necessary to accomplish a common task like this.