Improving the FileSystem Provider through Community feedback

Improving the FileSystem Provider through Community feedback

  • Comments 7

One of the things we love about the Windows PowerShell community is that folks are not shy. It turns out that having a vocal community is a great way to build and evangelize a product like ours. Of course, the Unix guys had this all figured out a long time ago.

Positive comments are good and all, but it’s difficult to really improve without being told where we came short. One of the ways we take feedback from the community for Windows PowerShell is through our public Microsoft Connect site. On that site anyone with a Live ID can log a bug or suggestion against Windows PowerShell. Items then get voted up or down by the community according to popularity.

We don’t get to implement every suggestion and fix every bug, but it’s a great way for us to understand what people are looking for and how important it is to them. With Windows PowerShell 3.0 we fixed over 200 items that were filed on Connect. This post will quickly touch on a few improvements to the FileSystem Provider based on this community feedback.

 

Support for Credentials

PowerShell MVP Joel Bennett filed a suggestion a few years ago asking that we support credentials with the FileSystem Provider. That suggestion was recently our 4th most voted item with 82 votes. The scenario is quite basic: You want to access a network file share, and that share requires a different set of credentials than the ones you are currently logged on with.

I’m happy to say that support for credentials on the FileSystem provider is available in Windows PowerShell 3.0! To use alternate credentials, simply use the Credential parameter on the New-PSDrive cmdlet

PS > New-PSDrive -Name J -PSProvider FileSystem -Root \\server001\sharename -Credential mydomain\travisj

Name           Used (GB)     Free (GB) Provider      Root      
----           ---------     --------- --------      ----      
J                                      FileSystem    \\server001\sharename

You can use all of the regular provider cmdlets like Get-ChildItem, Set-Location and Copy-Item against this new PSDrive just as you would normally – no need to specify the credentials over and over.

It gets better! By specifying the Persist switch parameter to the New-PSDrive cmdlet, the PSDrive will stay mounted across sessions. That line would look like:

PS > New-PSDrive -Name J -PSProvider FileSystem -Root \\server001\sharename -Credential mydomain\travisj -Persist

 

Moving items across drives

While we’re on the subject of the provider cmdlets, I want to mention that Move-Item can now move items across PSDrives. Using the PSDrive created above, we can move items from the network share (that was even mounted using a different set of credentials) to a location on the local file system. This one-liner will copy all XML files from the network share to a temporary directory on my computer.

Move-Item -Path J:\*.xml -Destination C:\temp

 

LiteralPath Parameter

Finally, we know that users have experienced difficulty working with files that contain characters like ‘[‘ or ‘]’. To help with this in Windows PowerShell 2.0, we added the LiteralPath parameter to some of the provider cmdlets. With Windows PowerShell 3.0, we have now added
LiteralPath to the Rename-Item cmdlet (the last of the provider cmdlets) and in many other places. LiteralPath is now available on 49 different cmdlets in Windows PowerShell 3.0!

 

Now that you’ve read this post, head on over to our Connect site and file a suggestion or bug for us. Or vote someone else’s up.

 

Travis Jones [MSFT]
Program Manager - Windows PowerShell
Microsoft Corporation

Leave a Comment
  • Please add 3 and 1 and type the answer here:
  • Post
  • But still no transactional file system. :(

  • By any chance has Get-ACL been updated to support -LiteralPath?  That's the one that get's me all the time

  • @Josh: Is TxFS support a connect item?  If it isn't, it can get voted on and prioritized.  I think we need to all be realistic about expectations.  For example, I wouldn't personally vote on a such a feature: It's pretty simple to do file system operations and simply capture errors, so I'd prefer that the limited resources of the PowerShell team be used elsewhere myself.

  • Luke - Yes. Get-ACL has been updated to support LiteralPath.

  • I don't like Connect as it is clumsy to use. The UI is slow and the search is bad.

    Example: I have filed a suggestion on improving the .. operator in order to also accept a step value, e.g. 1..10..2 to give you (1, 3, 5, ..., 10), but when I now search for ".. operator" on Connect, my suggestion is nowhere to be found. Badly designed site.

  • New to PowerShell. I found that all the file related commands required me to work hard to find directorys or sub directorys. Could we a simple swithch for directory. It all seemed simpler with batch files ie "dir c:\*.* /ad

  • Hi Matt - One of the improvements made this release is the addition of a Directory switch parameter to Get-ChildItem. That means that the following commands will all work

    Get-ChildItem -Directory

    dir -Directory

    dir -ad

    Thanks

    Travis Jones [MSFT]

Page 1 of 1 (7 items)