Friday Fun: Get Recent Files

As you might imagine, I work on a lot of different files throughout the week. Sometimes it is hard to keep everything straight. I’ll want to return to script I was working on yesterday, but I can’t remember what I called it. So I spend a few minutes searching and filtering until I find it. That takes too long. So why not create a simple PowerShell tool and load it into my profile?

First, I need a date to filter with. I want to find all files that were last modified yesterday.

If I just used the AddDays method, I would get exactly 24 hours from now, including the time. But I want since midnight. That’s what the Date property gets me. The value of $y is something like Thursday, March 19, 2015 12:00:00 AM. Now it is a simple matter of getting a directory listing and filtering with this date.

I need to make sure I sort the results but do so at the end so that PowerShell is sorting the filtered results.

Naturally I don’t want to have to type that all the time. So here is a function to do the work for me.

I set the default to find all files in the current folder last modified since yesterday. I also added an option to limit the results to the newest X number of files. My scripts folder has 10 years-worth of files so this is very helpful.

I even created an alias.

By the way, if you set the Days parameter to 0 you’ll get files modified today. It also makes it easy to see what I’ve been working on.

I want to point out one other feature that you might find useful in your scripts. You’ll notice that I use parameter validation a lot. If a validation test fails, PowerShell throws an exception. But sometimes you may want something a bit more elegant. In this function, I wanted to validate that the path existed and that it was a FileSystem path. A path like HKLM: would test as True but be invalid for the function’s purpose.

Here’s the validation attribute:

When you use ValidateScript, the scriptblock must return $True or $False. If it is $False then you get the typical exception. In this case, if the path passes my tests I can tell PowerShell it is OK ($True) and the function proceeds. But if the path fails my test I’m going to write my own error message.

As is often the case in PowerShell you have to consider who will be using your tools or script and how will they respond to errors.

The only thing I haven’t done is include any comment based help, so I’ll leave that to you. Enjoy!

Friday Fun: Creating Sample Files

documentNot too long ago I came across a PowerShell snippet, probably via Twitter, that showed how to use a few classes from the System.IO namespace to create dummy files. Sadly I forgot the record where I saw this first mentioned. What I liked about the code I saw was the ability to create a dummy file of any size. You’re probably wondering why you would ever want to do this. Way, way back in the day when storage was expensive I used to create a few 100MB of dummy files using an old command line utility which I think was called creatfil.exe. The reasoning was that if the server started running out of disk space unexpectedly, I could delete the dummy files and buy myself a little time and breathing room. Fortunately, I think we’ve advanced where that technique is no longer necessary.

But, where you might want some dummy or sample files, is to simulate a user folder with a variety of files. You could use this test directory to hone your PowerShell scripts. Any you may have your own reasons for needing a bunch of sample files. So I took the original code and ran with it, as I usually do. I came up with a function called New-SampleFile.

The function will create a randomly sized file in the specified folder. The default is the current location. As you look through the code you’ll see I’ve added a test to verify the path and to make sure it is a FileSystem path and not something like the registry. Also by default the function will use a randomly generated file name which will be something like rcstwqyg.34e. Personally, I’m going to specify a filename. The function will create the file of a random size between 5 bytes and the value of the MaximumSize parameter, which has a default of 100KB.

The function will not overwrite existing files unless you use –Force. Nor will you see any output unless you use –Passthru. Even those are common parameters, I had to write the PowerShell expressions to implement them. The same is true of –WhatIf. You’ll see in the cmdletbinding attribute that the function supports ShouldProcess. However, the .NET classes I’m calling have no concept of WhatIf. I had to handle that myself

Here’s the function in action:

This also makes it easy to create multiple files.

Or how about this? I want to create a variety of files with different names.

Now I have some test files I can work with

Normally I prefer to use cmdlets wherever possible. But since there is no cmdlet from Microsoft to create dummy files, I have no problem resorting to the .NET Framework. However, I think it is still worth the time to wrap the .NET commands in a user-friendly and easy to use advanced function as I’ve done today.

If you find a way to use this function, I hope you’ll let me know.

Friday Fun: The Measure of a Folder

rulerLast week, I demonstrated how to measure a file with PowerShell. This week let’s go a step further and measure a folder. I’m going to continue to use Measure-Object although this time I will need to use it to measure numeric property values.

Here’s the complete function after which I’ll point out a few key points.

The command will use the current path or you can pipe in a directory name, or the output of a Get-ChildItem expression as I show in the help examples. One thing I added is that I test the path to make sure it is a file system path because anything else wouldn’t really work.

I resolve the path so that I can get the actual name of the current location (.) and then test the provider. The other interesting feature of this function is that I format the results on the fly.

The function has a Unit parameter which has a default value of bytes. But you can also specify one of the PowerShell numeric shortcuts like KB or GB. In the function I use a Switch construct to create a custom property on the fly.

Because there can only be a single value for $Unit, I’m including the Break directive so that PowerShell won’t try to process any other potential matches in the Switch construct. Realistically, there’s a negligible performance gain in this situation but I wanted you to see how this works.


I’ve taken some basic commands you could use interactively such as Get-ChildItem and Measure-Object and built a tool around them using a hashtable of properties to create a custom object. I hope you pick up a tip or two from this. If you have any questions about what I’m doing or why, please don’t hesitate to ask because someone else might have the same question.

Enjoy your weekend!

Get Top Level Folder Usage

This is too long to tweet, even written as a one liner. But this will search a folder for top level subfolders and return the file usage for each.

[cc lang=”PowerShell”]
dir $folder | where {$_.psIscontainer} | foreach {
$stat= dir $_.fullname -recurse | Measure-Object -property length -Sum
New-Object PSObject -property @{Folder=$_.FullName;Files=$stat.count;Size=$stat.Sum;}}

Again, this would be handy to turn into a function or scriptblock. This is far from perfect. For example, it doesn’t like empty folders. But this should be a good starting point for your own script or function.

Friday the 13 Script Blocks

In celebration of Friday the 13th and to help ward off any triskaidekaphobia I thought I’d offer up 13 PowerShell scriptblocks. These are scriptblocks that might solve a legitimate business need like finding how long a server has been running to the more mercurial such as how many hours before I can go home.

A scriptblock is any small piece of PowerShell code enclosed in a set of curly braces. I say small, but there’s really no limit. You can even pass parameters to a script block. In this way they are like functions but without the function key word. Save the script block to a variable and when you want to execute, use the invoke operator, the & character. For example, here’s one of my luck 13 script blocks.
[cc lang=”powershell”]
#1. Get running services
$running={Param ([string]$computername=$env:computername) get-service -computername $computername |
where {$_.status -eq “Running”}}
To invoke it:
[cc lang=”powershell”]
PS C:\> &$running
Because this particular script block takes a computername as a parameter I could also do this:
[cc lang=”powershell”]
PS C:\> &$running Server01
I won’t post the complete script here, but these are the goodies:
#1. Get running services
#2. Get logical disk information
#3. Get day of the year
#4. Get top services by workingset size
#5. Get OS information
#6. Get system uptime
#7. get a random number between 1 and 13
#8. How old are you?
#9. get %TEMP% folder stats
#10. Get event log information
#11. Get local admin password age in days
#12. Get cmdlet summary
#13. How much time before I can go home?

I wrote many of the script blocks so that you could use them in your own functions and scripting and tried to make them re-usable as possible. They have no error handling and assume you have all the necessary permissions. Think of them as quick and dirty PowerShell snippets. The script file is simply defines the 13 script blocks. After each one is a commented example of how you might run it.

Again, I’m not promising anything life-changing but I hope you’ll have fun with them today. Download the script file 13ScriptBlocks.ps1.