PSProvider development: Get-ChildItem calls GetItem

by

I have a class that extends ContainerCmdletProvider, in which I’ve overridden the following methods: NewDrive, IsValidPath, ItemExists, HasChildItems, GetItem and GetChildItems.

I can create a new drive (New-PSDrive -Name test ...), and successfully the child items from the root (Get-ChildItem test:). But when I try it on a sub-path that I know exists and has children (Get-ChildItem test:path) I get the same result as if I had run Get-Item test:path.

Using a debugger and setting breakpoints I can see which methods are called.
For Get-ChildItem test: it’s, ItemExists, GetChildItems.
For Get-ChildItem test:path it’s, ItemExists, GetItem.

Is this the expected behaviour? If so, how can I know the user’s intention (viewing the item or its children)?
I’m surprised HasChildItems isn’t called.

To output the test:path item, from both GetChildItems and GetItem, I use WriteItemObject(item, itemPath, true) passing the isContainer flag as true.

I’ve been following the How to Create a Windows PowerShell Provider guide from Microsoft. I’m targeting PowerShell Core (I’m on version 7.3.7), but this is the only guide I’ve found.

  • Do you need the backslash? Get-Item test:\path. When you leave the backslash off in windows it will take the current selected directory. So if you have test:\root\folder1\path. If current folder is root you will not find the subfolder path.

    – 

  • 1

    I’ve played around with different combinations of slashes (test:\path, test:path`, test:\path`) but they all result in the same behaviour. Regardless, I’d never expect GetItem to be called when executing Get-ChildItem…

    – 

  • You may not have permission to read folder. Try starting PS by right click shortcut and select Run As Admin.

    – 

  • @jdweng That didn’t make any difference, but I appreciate the help

    – 

  • @jdweng: There is nothing in this question that even remotely suggests that a permissions problem is involved. Given the security risks involved, running code with elevation (as administrator) should always be a deliberate act that should be limited to operations that actually require elevated privileges. Casually suggesting it as a cure-all, which you seem to be in the habit of doing, does more harm than good.

    – 

Leave a Comment