« Scheduling and Black Hole Projects | Main | MSN Toolbar Suite is the Command Line of the Future? »

December 13, 2004

Monad Providers and UNC Names

A week or so ago I mentioned in another post that Monad just gained the ability to directly access UNC filenames that begin with "\\server\share".

UNC stands for Univeral Naming Convention and it was something Microsoft came out with first in Windows NT. In the DOS LAN Manager days, you had to first "net use" to a file share, which would assign it a drive letter, and then use the drive letter in filepaths. NT still allowed "net use" (it let you specify credentials, and some existing software wouldn't allow paths that started with "\\"), but you could also just specify the UNC name directly. NT also had something called the MUP, which would allow different client redirectors a chance to claim a UNC name (the effect being that you could access \\server\share without knowing if it was on an NT or Netware server).

Anyway, Monad did not use to support UNC names unless you prefixed them with the string "FileSystem::" (as in "FileSystem::\\server\share"). To understand why, first you have to understand Monad providers. Monad has a provider model which allows various components to expose themselves to the standard Monad navigation cmdlets. For example, you could do the following:

get-childitem registry::\

(get-childitem is equivalent to dir and in fact is aliased as such, but I'll use the Monad terms) and it spits out a list like


and then you can do

set-location registry::
get-childitem HKEY_LOCAL_MACHINE

and it would show


The filesystem is just another provider, whose prefix is "FileSystem::". If you specify a path without a provider name in front, then it is assumed to be in the current provider (which is changed with set-location). So normally your current location is in the filesystem provider and paths like "\WINDOWS" work as expected, but if you are another provider they won't.

On top of this you have drives. For example "C:" is a drive. Drives are associated with a specific provider, so "C:\WINDOWS" will always refer to the filesystem provider, no matter what the current location. "HKLM:" is a drive on the registry provider, so similarly "HKLM:\HARDWARE" will work no matter what the current location.

Now comes the question of how to handle a path like "\\server\share\file". These paths are handled by the filesystem, and a path like "FileSystem::\\server\share\file" has always worked. But without the "FileSystem::" in front, there was a debate within Monad about whether a path starting with "\\" should be special-cased to always refer to the FileSystem provider, or should it be provider-relative (because, as one example, a path like "Registry::\\server\key" makes some sense for refering to a remote registry).

It was one of those situations where you know the current behavior is not good, but you get stuck choosing between two ways to improve it, and not doing either. It's not like there was even an installed Monad base to worry about, so we could set the "rules" however we wanted. Eventually the decisions was made to have the "\\" paths be provider-relative. So UNC names only work if your current location is in the FileSystem provider.

Most people won't even care about the distinction because their current location will always be on the FileSystem provider. For people who do things like

set-location registry::\
get-childitem HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Confi guration > FileSystem::\\myserver\data\config.txt

they will have to include the "FileSystem::" part as shown above. I think users who do things like that will be able to understand why it is needed.

Posted by AdamBa at December 13, 2004 01:30 PM

Trackback Pings

TrackBack URL for this entry:


look, monad cant be successful whatever it is. Not when it rhymes with gonad

Posted by: immature at December 16, 2004 09:44 PM

"Eventually the decisions was made to have the "\\" paths be provider-relative."

Do I understand correctly that a provider now can choose if it makes sense for it to support remote-scenarios (like the filesystem and registry providers) or not (like the alias provider etc)?

If that is correct, where does a cmdletprovider decide this? Just to set a ProviderCapabilities-flag, or must it handle "\\" cases properly in the affected methods such as the NewDrive, GetItem etc. methods? [If this is too Monad-specific and not allowed to be discussed here, please remove the comment :)]


Posted by: Andreas Häber at December 16, 2004 09:53 PM

Andreas: the paths with \\ are passed to the provider as-is, and the provider can do what it wants with them. There's no capabilities flag, the Monad engine doesn't do any processing on the paths (for example splitting out the \\ part from the rest ).

- adam

Posted by: Adam Barr at December 17, 2004 12:18 PM