Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

A UNC name failure...

M

mathewsdw

May
855
0
The best bet is, as usual, to just show the transcript of a short TCC session:
Code: 
   Fri  Jan 11, 2013   6:19:58p
 
[Z:\]PushD \\Live.Sysinternals.com
TCC: (Sys) The specified path is invalid.
 "\\Live.Sysinternals.com"

[Z:\]cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

Z:\>PushD \\Live.Sysinternals.com

X:\>Dir tcp*
 Volume in drive X has no label.

 Directory of X:\

07/28/2010  08:47 AM           199,544 tcpvcon.exe
07/02/2010  09:03 AM            41,074 tcpview.chm
07/25/2011  05:40 AM           300,832 Tcpview.exe
09/02/2002  06:13 AM             7,983 TCPVIEW.HLP
               4 File(s)        549,433 bytes
               0 Dir(s)  66,620,633,088 bytes free

X:\>Exit

[Z:\]PushD \\Live.Sysinternals.com
TCC: (Sys) The specified path is invalid.
 "\\Live.Sysinternals.com"
As you can see, what works fine in cmd.exe fails miserably in TCC.

No other comments.
 
mathewsdw said:
The best bet is, as usual, to just show the transcript of a short TCC session:
Code: 
  Fri  Jan 11, 2013  6:19:58p
 
[Z:\]PushD \\Live.Sysinternals.com
TCC: (Sys) The specified path is invalid.
"\\Live.Sysinternals.com"
 
[Z:\]cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
 
Z:\>PushD \\Live.Sysinternals.com
 
X:\>Dir tcp*
Volume in drive X has no label.
 
Directory of X:\
 
07/28/2010  08:47 AM          199,544 tcpvcon.exe
07/02/2010  09:03 AM            41,074 tcpview.chm
07/25/2011  05:40 AM          300,832 Tcpview.exe
09/02/2002  06:13 AM            7,983 TCPVIEW.HLP
              4 File(s)        549,433 bytes
              0 Dir(s)  66,620,633,088 bytes free
 
X:\>Exit
 
[Z:\]PushD \\Live.Sysinternals.com
TCC: (Sys) The specified path is invalid.
"\\Live.Sysinternals.com"
As you can see, what works fine in cmd.exe fails miserably in TCC.

No other comments.
Click to expand...
What's "\\" supposed to mean? When I try with CMD I get (as expected)
Code: 
V:\> dir a.*
Volume in drive V is DATA
Volume Serial Number is C007-D3E4
 
Directory of V:\
 
2013-01-11  19:53    <DIR>          a.b.c
              0 File(s)              0 bytes
              1 Dir(s)  6,798,684,160 bytes free
 
V:\> pushd \\a.b.c
The network name cannot be found.
 
Vince, that is simply because there is no entity named "a.b.c" on the internet (like any directory it must exist for you to "PushD" into it). However, there is an entity on the internet named "Live.Sysinternals.com" (the leading double slashes are what make it a UNC name). I will also note that "PushD \\Live.SysInternals.com\Tools" works in both cmd.exe and TCC (although somewhat differently, and I think that most people would think that TCC's handling of it is better). And I have to ask, did you think I faked the TCC session listing?
 
I don't see how that could be a valid UNC name. There's no sharename!
 
Boy, Charles, I really don't understand. Again, did you think that the TCC session listing I put in my posing was a fake? Try it yourself! The command is "PushD \\Live.SysInternals.com\Tools". (Again, "PushD \\Live.SysInternals.com" works in cmd.exe but not in TCC.)
 
The bit after the first two backslashes is the server name (live.sysinternals.com in your example); the part after the third backslash is the sharename; and everything after the fourth backslash is the path and filename under the share. (And the server is usually local, not out there on the internet somewhere.)

I truly don't understand how CMD.EXE is handling a server name without a sharename; connecting to IPC$ maybe?
 
Charles, since this is something I just (rather accidentally) "discovered", I can't speak to your answer other than tos say that from all of my experimentation and testing "Tools" certainly seems to be a directory name and not a share name. (It behaves like a directory in all respects.) I don't know what else to tell you other than try it yourself if you haven't already (with the restriction I brought up for TCC).
 
This is (1) completely undocumented CMD (internally hard-wired) behavior, and (2) an invalid UNC any way you look at it.

If you use the actual UNC name, TCC can handle it (better than CMD, because TCC doesn't have to map a local drive to the UNC):

pushd \\live.sysinternals.com\tools
 
Rex, first I said that TCC does handle it better (cosmetically!) than does cmd.exe. Secondly, I can't speak to anything being undocumented other to say that this is also supported when opening a GUI window (Start \\Live.SysInternals.com works perfectly opening a directory window at the "root" of "Live.SysInternals.com"). It also works directly from the Windows GUI so it is not some capability limited just to cmd.exe. To verify this for yourself open a GUI window on any directory (it doesn't matter at all which one) and then click in the GUI window's "location" bar (but on a blank area in the bar, not on the actual the contents of the bar) and type in "\\Live.SysInternals.com" and you can see for yourself what you get.
 
Sorry Rex, I don't agree. This would probably not be documented for cmd.exe because it is also the behavior of the Windows GUI (in Windows 7, at least) and therefore Windows as a whole so, while it may be undocumented (I don't know where to find the documentation, either), it is definitely quite intentional and not a bug. (Of course it is your choice as to whether you choose to support it.)
 
http://technet.microsoft.com/en-US/sysinternals
Sysinternals Live

Sysinternals Live is a service that enables you to execute Sysinternals tools directly from the Web without hunting for and manually downloading them. Simply enter a tool's Sysinternals Live path into Windows Explorer or a command prompt as http://live.sysinternals.com/<toolname> or \\live.sysinternals.com\tools\<toolname>.
You can view the entire Sysinternals Live tools directory in a browser at http://live.sysinternals.com.
Click to expand...

So technically, from the command prompt at least, the \tools share name should be used.
 
Why does everybody ignore the reality that what works works? This is clearly not an accident on the part of "SysInternals" (and they would say what they say if this doesn't work in prior version(s) of Windows), nor is it an accident for the Windows GUI. Again, it is up to Rex if wants to support it; I can easily work around his lack of support by doing:
Code: 
cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
 
Z:\>pushd \\Live.Sysinternals.com
 
X:\>
TCC
X: :: If needed
 
:: Whatever you want to be doing...
 
Exit :: Exists the "inner" TCC
Exit :: Exists cmd.exe
:: At this point back in the original instance of TCC
 
And I also have to add that System Internals would probably have the presumption that they are going to be accessed via a web browser. (No browser is involved in any of the previous, of course). And I will note that "\\Live.SysInternals.com" is accepted as a valid (sort of) URL for Internet Explorer (not Firefox, at least at the present moment), although the "sort of" qualification is because Internet Explorer, believe it or not, opens a Windows GUI window directly on the desktop and not within Internet Explorer.
 
Sorry Dan! I didn't intend to ignore that it works. It is indeed strange that it does work! I was just trying to find M$' official word on accessing that share. :)

I've actually been investigating this using their TCPView and it seems as though when the normal netbois calls don't succeed, probably because of port blocking by ISPs, then HTTP is used instead. Maybe that's why just live.sysinternals.com works, because of the files at the root of the web server.

But.. interestingly dir \\live.sysinternals.com in cmd.exe does not work and gives "The filename, directory name, or volume label syntax is incorrect." o_O
 
mathewsdw said:
And I also have to add that System Internals would probably have the presumption that they are going to be accessed via a web browser. (No browser is involved in any of the previous, of course). And I will note that "\\Live.SysInternals.com" is accepted as a valid (sort of) URL for Internet Explorer (not Firefox, at least at the present moment), although the "sort of" qualification is because Internet Explorer, believe it or not, opens a Windows GUI window directly on the desktop and not within Internet Explorer.
Click to expand...
That's because Windows Explorer really is Internet Explorer ...or is it the other way around? ;)
 
mathewsdw said:
Code: 
cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
 
Z:\>pushd \\Live.Sysinternals.com
 
X:\>
TCC
X: :: If needed
 
:: Whatever you want to be doing...
 
Exit :: Exists the "inner" TCC
Exit :: Exists cmd.exe
:: At this point back in the original instance of TCC
Click to expand...
Why not just pushd \\Live.Sysinternals.com\tools (since they're the same files, see below) and stay in the original instance of TCC?

http://live.sysinternals.com/
http://live.sysinternals.com/tools/
 
Sorry I didn't make something clear here: To access the internet resource from cmd.exe in the first place, you must do a "PushD <internet URL>" (any form of CD does not work). (The Windows GUI doesn't have this restriction although it is a strange methodology. And going directly through the Windows GUI does not appear (at least) to assign any kind of drive letter to the internet resource.) If you did the "PushD" command at a command prompt the internet resource is accessible via a drive letter created when you executed the PushD command (that is persistent and visible to all current and future running instances of a command prompt (both cmd.exe and TCC) until you exit the cmd.exe where you did the "PushD" command in the first place) but can not be seen by the either double-clicking on the "My Computer" icon on the desktop nor by any "subst" command). And I'm not really sure if this has anything to do with what you say above, but you can do "PushD \\Host[\TopLevelDirectory[\NextLevelDirectory[\AndNextLevelDirectory...]]]" to CD anywhere on the "host" that you want to go. (The "host" is effectively the "root" directory irregardless of what drive/directory it may be on the "host" machine). Note that there is no "share name" here, it is a totally irrelevant concept.
 
Because that PushD does not work for the root directory (PushD \\live.sysinternals.com) in Take Command/TCC, which is where I started this whole thread in the first place.
 
After I "pushd ..." in CMD, I see, in MyComputer, "NetworkLocation(1) DavWWWRoot(\\Live.Sysinternals.com) (Z:)". It persists (don't know how long) after closing CMD.
 
mathewsdw said:
Charles, since this is something I just (rather accidentally) "discovered", I can't speak to your answer other than tos say that from all of my experimentation and testing "Tools" certainly seems to be a directory name and not a share name. (It behaves like a directory in all respects.) I don't know what else to tell you other than try it yourself if you haven't already (with the restriction I brought up for TCC).
Click to expand...

Dan, I'm not arguing that it works as you say it does. I'm just saying that I don't think the first example you gave (sans sharename) is a valid UNC name. It's a server name, part of a UNC name but not a whole one.

And yes, I do know that Explorer does support \\servername to display the non-hidden shares on a server -- depending on how the server is configured; cautious sysadmins may disable that feature. You can type \\servername into the Start/Run dialog too, as a quick way to see what a Windows server is offering. But I'm very surprised that CMD.EXE permits it.
 
Charles, you have explained a minor mystery but just opened up other ones. You see, what looks like the files in the "root" directory ("\\Live.SysInternals.com" itself) do not show up in the Windows Explorer GUI window, all that show up there is the "shares" (I hadn't noticed this, but then I'm half blind) which operate exactly like directories from the perspective of the user of the GUI. However, the contents of the apparent "root" directory (\\live.sysinternals.net) are not the same as the contents of any of the shares (which, again, you can just CD into in cmd.exe), and not only that each of the so-called "shares" in Windows Explorer show up as a subdirectory of "\\Live.SysInternals.com". So the mystery is "What is this thing called "\\Live.SysInternals.com" if it is not a share (and does not show up as being a share in Windows Explorer, only a container that contains shares and nothing else). And why does "\\Live.SysInternals.com" have quite different contents itself than any of its subdirectories (which, again, are what show up as "shares" in Windows Explorer) and why doesn't the contents of it, itself, show up in Windows Explorer, i.e, the GUI view of "\\Live.SysInternals.com" is actually quite different than the view of the same entity as seen by either cmd.exe or even TCC when run from within cmd.exe. I don't know the answers to these questions, I just know that this is how they are from the perspective of cmd.exe (and TCC when run from cmd.exe).

Supporting evidence

First, a table summarizing all of the file and subdirectory counts of all of the directories as seen by cmd.exe (and TCC when run from cmd.exe):

________________________________________Files in_____Executables
_______________________________________Directory____in Directory
___________\\Live.SysInternals.com\Files_______70___________0
____\\Live.SysInternals.com\aspnet_client________2__________ 0
__________\\Live.SysInternals.com\Tools______104__________74
\\Live.SysInternals.com\WindowsInternals_______10___________5
______________________________Total______186__________79

_______________\\Live.SysInternals.com______111__________74


________________________________________Files in______Executables
_______________________________________Directory_____in Directory
________________________________________and__________and
____________________________________Subdirectories__Subdirectories
___________\\Live.SysInternals.com\Files_______77___________0
____\\Live.SysInternals.com\aspnet_client________2__________ 0
__________\\Live.SysInternals.com\Tools______114__________79
\\Live.SysInternals.com\WindowsInternals_______10___________5
______________________________Total______203__________84

_______________\\Live.SysInternals.com______314_________158


And here are the various directory structures:

\\Live.SysInternals.com\Files
└──WindowsInternals

\\Live.SysInternals.com\aspnet_client

\\Live.SysInternals.com\Tools
└──WindowsInternals

\\Live.SysInternals.com\WindowsInternals

Note that "X" is mapped directly
to \\Live.SysInternals.com
X:\
├──aspnet_client
├──Files
│ └──WindowsInternals
├──Tools
│ └──WindowsInternals
└──WindowsInternals

more in my next posting...
 
And what the Windows GUI sees is in an attached .zip file containing a portable network graphics (PNG) file.

And just to prove I'm not making anything up, here's an unedited transcript of the TCC (and cmd.exe) session from which I derived all of the figures in my last posting:

Code: 
  Sat  Jan 12, 2013  5:35:34p
 
CC  14.03.53 x64  Windows 7 [Version 6.1.7601]
Copyright 2012 JP Software Inc.  All Rights Reserved
Registered to Daniel Mathews
 
[Z:\]PushD \\Live.SysInternals.com\Files
 
[\\Live.SysInternals.com\Files]Echo %@Files[*] %@Files[*.exe] %@Files[/S *] %@Files[/S *.exe]
70 0 77 0
 
[\\Live.SysInternals.com\Files]Tree
 
\\Live.SysInternals.com\Files
└──WindowsInternals
 
[\\Live.SysInternals.com\Files]PopD
 
[Z:\]PushD \\Live.SysInternals.com\aspnet_client
 
[\\Live.SysInternals.com\aspnet_client]Echo %@Files[*] %@Files[*.exe] %@Files[/S *] %@Files[/S *.exe]
2 0 2 0
 
[\\Live.SysInternals.com\aspnet_client]Tree
 
\\Live.SysInternals.com\aspnet_client
 
[\\Live.SysInternals.com\aspnet_client]PopD
 
[Z:\]PushD \\Live.SysInternals.com\Tools
 
[\\Live.SysInternals.com\Tools]Echo %@Files[*] %@Files[*.exe] %@Files[/S *] %@Files[/S *.exe]
104 74 114 79
 
[\\Live.SysInternals.com\Tools]Tree
 
\\Live.SysInternals.com\Tools
└──WindowsInternals
 
[\\Live.SysInternals.com\Tools]PopD
 
[Z:\]PushD \\Live.SysInternals.com\WindowsInternals
 
[\\Live.SysInternals.com\WindowsInternals]Echo %@Files[*] %@Files[*.exe] %@Files[/S *] %@Files[/S *.exe]
10 5 10 5
 
[\\Live.SysInternals.com\WindowsInternals]Tree
 
\\Live.SysInternals.com\WindowsInternals
 
[\\Live.SysInternals.com\WindowsInternals]PopD
 
[Z:\]CMD
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
 
Z:\>PushD \\Live.SysInternals.com
 
X:\>TCC
 
TCC  14.03.53 x64  Windows 7 [Version 6.1.7601]
Copyright 2012 JP Software Inc.  All Rights Reserved
Registered to Daniel Mathews
 
Z:\>X:
 
X:\>Echo %@Files[*] %@Files[*.exe] %@Files[/S *] %@Files[/S *.exe]
111 74 314 158
 
X:\>Tree
 
X:\
├──aspnet_client
├──Files
│  └──WindowsInternals
├──Tools
│  └──WindowsInternals
└──WindowsInternals
 
X:\>Exit
 
X:\>PopD
 
Z:\>Exit
 
[Z:\]
You (and Rex) can make of this what you will.
 

Attachments

Okay, so I just tried PUSHD \\LIVE.SYSINTERNALS.COM from within CMD.EXE; and then did a NET USE, which showed the temporary drive Z: as being mapped to \\LIVE.SYSINTERNALS.COM\DAVWWWROOT. (I'm guessing that this share is for WebDAV support, about which I know practically nothing; and that the server is somehow automagically adding the DAVWWWROOT in lieu of the missing sharename.)

You can, therefore, accomplish the same thing in TCC via
Code: 
pushd \\live.sysinternals.com\davwwwroot
 
mathewsdw said:
Vince, all I can say is that doesn't happen for me (and I just did it again from scratch and checked). Strange.
Click to expand...

According to Wikipedia's entry on WebDAV, Microsoft has released two fundamentally different WebDAV clients for Windows -- and which one you're using will depend not only on your Windows version, but also on whether you have Office installed. So I guess it's quite possible that the two of you are seeing utterly different behaviors.
 
Charles, I also did a Google search for davwwwroot, and didn't come up with much that I could really understand (but a whole lot of stuff about SharePoint, none of which made much immediate sense to me). However, it would appear that davwwwroot is sort of an "invisible" share (i.e., not displayed by those things, such as Windows Explorer, which show shares). I must admit that I have my past weighing down on me to a degree here, I once was a Novell (remember them? Although they apparently do still exist) CNE (Certified Netware Engineer) and CNI (Certified Netware Instructor), but that was in the days when Microsoft's networking technologies were just beginning to be developed. But it's good to know that that is what could work as a share when a "normal" share doesn't exist or isn't specified (i.e., just the server name), and this also sort of implies that Rex, should he choose to do so, can (rather easily, I would think) see if he can connect with a share of that name when no share is explicitly specified (as cmd.exe apparently does), fail if "davwwwroot" isn't really there (as he would fail on any missing/invalid share name), and transparently use it if it does exist. The only real question, it seems to me, is what error message to produce if this fails when no share name was specified (I know of no way for me to determine on a non-networked home computer what cmd.exe produces in this situation), reporting that that specific "share" (davwwwroot) is not found could be confusing and unhelpful to the end user if he didn't know that that was the (pseudo at least) share name that was being used. Or, if nothing else, he could put a reference to davwwwroot is his documentation as being a sort of "default" share name that might be usable when no explicit share name is given.
 
I think SharePoint is becoming important factor in the business world. To quote the Wikipedia article on the subject: "SharePoint is used by 78% of Fortune 500 companies". So what I ran into is probably not that rare.
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate