UNC paths in cmd.exe

[Sid Knee]

I posted earlier about a problem I was having when trying to use a right
click command (which utilises cmd.exe) on a network path. Dave Patrick
kindly directed me to the reghack at:

http://support.microsoft.com/kb/156276

I've now tried this on several machines and it still doesn't (quite)
work. What happens now if I use a right click command to, say, open a
command window in the (network) directory I'm pointing at is that I
still get the pre-hack failure message:

"Invalid directory path, UNC paths are not supported"

However, whereas before it then defaulted back to c:\winNT, it now
defaults to the next higher directory level - which is still a UNC path
anyway!

e.g. if I'm trying to open a window in \\netpath\myfiles\test, it
refuses to open in that directory but opens in \\netpath\myfiles instead.

I really would like to get this to work (ultimately it's actually a CAD
file purge command that I need to get working). Any ideas?

Note: the Microsoft article says to obtain "the new copy of cmd.exe" as
well as doing the registry change. However, there was no reference or
link for a new cmd.exe and since the page was written originally in NT4
days, I presumed Win2K already contained the new version. Could it be
that there is still another version around?

 

[Herb Martin]

I posted earlier about a problem I was having when trying to use a right
click command (which utilises cmd.exe) on a network path. Dave Patrick
kindly directed me to the reghack at:

http://support.microsoft.com/kb/156276

I've now tried this on several machines and it still doesn't (quite)
work. What happens now if I use a right click command to, say, open a
command window in the (network) directory I'm pointing at is that I
still get the pre-hack failure message:

"Invalid directory path, UNC paths are not supported"

However, whereas before it then defaulted back to c:\winNT, it now
defaults to the next higher directory level - which is still a UNC path
anyway!

e.g. if I'm trying to open a window in \\netpath\myfiles\test, it
refuses to open in that directory but opens in \\netpath\myfiles instead.

I really would like to get this to work (ultimately it's actually a CAD
file purge command that I need to get working). Any ideas?

It won't fix "this problem" but it might serve your purpose
just as well to recognize that you don't have to "be in a
directory" (have it as default directory) to perform actions
there -- you can just script the deletes (or whatever) using
the UNC path which is supported.

Only the "default directory" is the real problem.

Note: the Microsoft article says to obtain "the new copy of cmd.exe" as
well as doing the registry change. However, there was no reference or
link for a new cmd.exe and since the page was written originally in NT4
days, I presumed Win2K already contained the new version. Could it be
that there is still another version around?

Doubt that -- I read the article the same as you -- "new"
was relative to NT 4 and although the registry hack still
applies to newer systems I strongly suspect that the newer
systems already have the update (or are supposed) to understand
the registry hack.

 

[Sid Knee]

It won't fix "this problem" but it might serve your purpose
just as well to recognize that you don't have to "be in a
directory" (have it as default directory) to perform actions
there -- you can just script the deletes (or whatever) using
the UNC path which is supported.

Only the "default directory" is the real problem.

Interesting thought. Ultimately what I'm trying to run is a third-party
cad file purge utility. However, that utility is written as a .BAT file
so there may indeed be a possibility of doing it the way you say.

The only other way around it that i came up with is to create a dummy
folder in the directory of interest and point to that. cmd.exe would
refuse to go to the dummy directory and settle for the next level up ...
which is actually the directory that I want. Bit kludgey though.

Thanks, Herb.

 

[Stefan Kanthak]

I posted earlier about a problem I was having when trying to use a right
click command (which utilises cmd.exe) on a network path. Dave Patrick
kindly directed me to the reghack at:

http://support.microsoft.com/kb/156276

I've now tried this on several machines and it still doesn't (quite)
work. What happens now if I use a right click command to, say, open a
command window in the (network) directory I'm pointing at is that I
still get the pre-hack failure message:

"Invalid directory path, UNC paths are not supported"

Which command line do you use for "Command prompt here"?

--- PROMPT.REG ---
REGEDIT4

[HKEY_CLASSES_ROOT\Directory\Shell\Prompt]
@="Command Prompt"

[HKEY_CLASSES_ROOT\Directory\Shell\Prompt\Command]
@=hex(2):25,53,79,73,74,65,6d,52,6f,6f,74,25,5c,53,59,53,54,45,4d,33,32,5c,43,\
4d,44,2e,45,58,45,20,2f,4b,20,50,75,73,68,44,20,22,25,31,22,00


[HKEY_CLASSES_ROOT\Drive\Shell\Prompt]
@="Command Prompt"

[HKEY_CLASSES_ROOT\Drive\Shell\Prompt\Command]
@=hex(2):25,53,79,73,74,65,6d,52,6f,6f,74,25,5c,53,59,53,54,45,4d,33,32,5c,43,\
4d,44,2e,45,58,45,20,2f,4b,20,50,75,73,68,44,20,22,25,31,22,00

--- EOF ---

The above command lines read "%ComSpec% /K PushD ""%L""" and work EVERYWHERE!

Stefan

 

[Sid Knee]

Which command line do you use for "Command prompt here"?

The one I'm using is under Filetype "File Folder" and the command line is:

cmd.exe /K cd %1

is that a problem for unc paths (it works fine with local paths)?

 

[Michael Bednarek]

The one I'm using is under Filetype "File Folder" and the command line is:

cmd.exe /K cd %1

is that a problem for unc paths (it works fine with local paths)?

Did you read Stefan's post to the end? Just use PUSHD as he suggested;
quotes around the parameter argument are a good idea, too. Further
reading: <http://support.microsoft.com/kb/317379>.

 

[Sid Knee]

Did you read Stefan's post to the end? Just use PUSHD as he suggested;
quotes around the parameter argument are a good idea, too. Further
reading: <http://support.microsoft.com/kb/317379>.

Yes, I did read it. My reply was in response to Stefan's question about
what *I* was using.

What amazes me is that, before I retired (3 years ago) I had this whole
thing working perfectly on Win2K pro (with my command line and no
registry changes). I can only assume that subsequent updates have
changed things.

Thanks for the further reading.

 

[Stefan Kanthak]

If "File Folder" is the friendly name of [HKCR\Folder] then this is not
the right place: folder subsumes drives [HKCR\Drive], directories
[HKCR\Directory] and (virtual) shell folders.
Did you ever try to use "Command prompt here" on the latter, especially
when the target is no real directory? Oops!

You use the bad implementation by the power toys. NOT GOOD!
It has the error you experience, the error I mentioned above and opens
a security hole: just place an arbitrary executable as CMD.EXE in some
directory and use the "Command prompt here". Oops!

Yes, I did read it. My reply was in response to Stefan's question about
what *I* was using.

I too suspected that you did not read any further: you did not provide
any feedback on the working solution I gave.

What amazes me is that, before I retired (3 years ago) I had this whole
thing working perfectly on Win2K pro (with my command line and no
registry changes). I can only assume that subsequent updates have
changed things.

This MUST be wrong. "cd \\server\share" doesn't work in any version of NT.
I'm using my version since 1997.

Thanks for the further reading.

Stefan

 

[Sid Knee]

I too suspected that you did not read any further: you did not provide
any feedback on the working solution I gave.

Please don't think that I hadn't read it, Stefan. I just hadn't yet
tried it so was unable to give feedback. I'm not a programmer (or even
close), the command line terms were unfamiliar to me and I was trying to
fully understand what it was doing before I use it. I shall be trying it
though.

And I do appreciate the help.

 

[Jason Gurtz]

The above command lines read "%ComSpec% /K PushD ""%L""" and work EVERYWHERE!

This looks really great but I wonder about a possible buildup of
temporary drive letters since POPD isn't being run.

I wonder if it's worthwhile constructing some kind (admittedly a cheap
hack) of workaround via a \tmp dir and associated entries along with
"spinlock" style drive letter removal?

~Jason

--