Getting Around: Providers, PSDrives & Navigating the Object Filesystem

Chapter 1 used Get-ChildItem (by way of its dir/ls/gci aliases) purely to list files, which makes it easy to read as "PowerShell's version of dir" and stop there. It's actually doing something bigger: Get-ChildItem, Set-Location, and the rest of PowerShell's navigation cmdlets don't know anything about files specifically at all. They know how to walk a generic, drive-and-item structure — and PowerShell ships several completely different things dressed up to look like that same structure. That's the provider model, and it's the reason a handful of cmdlets you already know can browse the registry, your environment variables, and your certificate store with zero new syntax to learn.

Providers: The Abstraction Underneath Every "Drive"

A PSProvider is a piece of PowerShell that takes some data store — a real filesystem, but also the Windows Registry, the current session's environment variables, even the certificate store — and exposes it as a hierarchy of drives, folders, and items. List every provider your session has loaded with Get-PSProvider:

cmd.exe has nothing resembling this — its dir only ever meant "a folder on a disk," full stop. Bash comes closer in spirit (Linux's own "everything is a file" philosophy exposes plenty of non-disk data as real files under /proc and /sys), but that's a kernel-level trick baked into the operating system itself. PowerShell's providers achieve a similar effect entirely at the shell layer, which is why the exact same list above includes things that have nothing to do with a hard drive at all.

PSDrives: Not Just C: and D:

Each provider exposes one or more PSDrives — and despite the colon-suffixed, drive-letter-looking name, most of them were never disks in the first place. Get-PSDrive lists every drive currently available to navigate:

C is the only row here backed by an actual disk. HKLM, Env, Cert, and the rest have no size at all, because "used/free gigabytes" is a filesystem-specific idea that simply doesn't apply once the underlying data isn't a disk — the Used/Free columns are blank for exactly that reason.

Navigating with the Same Cmdlets, Everywhere

Here's the payoff: Set-Location (aliased cd), Get-Location (aliased pwd), Push-Location/Pop-Location (aliased pushd/popd), and Chapter 1's own Get-ChildItem all work against any PSDrive, not just FileSystem ones — because they're written against the provider abstraction, not against "files" specifically:

Reading a Value: Get-ChildItem vs. Get-ItemProperty

One real gotcha shows up the first time you try to read an actual registry value rather than just list subkeys. In the filesystem, Get-ChildItem lists a folder's contents (its children) — but a registry key's values aren't children the way subkeys are; they're properties attached to the key itself. Listing children won't show them:

This is a case where the provider abstraction is genuinely leaky, not seamless — the registry's own key-vs-value split doesn't map perfectly onto a filesystem's folder-vs-file split, and Get-ItemProperty exists specifically to bridge that gap.

Every Built-In Provider, at a Glance

Creating Your Own PSDrive

Beyond the built-in ones, you can map any FileSystem path to a short custom drive name with New-PSDrive — handy for a deep or frequently-used folder:

New-PSDrive without -Persist only lasts for the current session — it disappears the moment you close the window, which is usually exactly what you want for a quick shortcut rather than a permanent change.

Where This Course Is Headed

Cmdlet syntax, discovery, and getting real help (Get-Help, Get-Command, Get-Member), the pipeline in real depth, variables and PowerShell's own type system, control flow, functions and script files, working with files/text/formatted output, error handling and basic debugging, execution policy and script security, and modules/aliases/the PowerShell Gallery — closing with a capstone automating a real administrative task end to end.

Hands-On Exercises