From: Dylan Penhale <dylan@(email surpressed).au>
Subject: UNC paths are not supported when including some custom mel scripts
   Date: Mon, 03 Jul 2006 02:58:03 -0400

Hi there

Custom Mel:

//print windows username
string $WIN_Username = `system("echo %USERNAME%")`;
print ("\nCURRENT WINDOWS USER:\n" + $WIN_Username);

Error:

CURRENT WINDOWS USER:
'\\na.fuel\share\projects\q\q_s245\q_245_176\setups\maya'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
netrender

Regards

Dylan Penhale
Systems Administrator
Fuel International
65 King Street
Newtown
2042
Sydney
Australia
p. (Tel# suppressed)
f. (Tel# suppressed)

On 3 Jul 2006 06:58:03 -0000, Dylan Penhale <dylan@(email surpressed).au> wrote:

We are running some custom mel when we submit a rush job and we get
an error about UNC paths. I looked up the error and it appears to
have been fixed a long time ago around the time of NT I think.

Hi Dylan,

I can replicate the same error here on Windows XP SP2 and as I recall
this have always been the case for most of the command line tools --
they don't do UNC.

I think "fixed" here means "we added a registry key to suppress the
error", unfortunately.

Custom Mel:

//print windows username
string $WIN_Username = `system("echo %USERNAME%")`;
print ("\nCURRENT WINDOWS USER:\n" + $WIN_Username);

You can get to environment variables through $ENV in perl, so the above
could be changed to string $WIN_Username = $ENV{'username'} and you could avoid
the problem altogether.

/Niklas
--
Swiss International | www.swiss.se

|I think "fixed" here means "we added a registry key to suppress the
|error", unfortunately.
|
|> Custom Mel:
|>
|> //print windows username
|> string $WIN_Username = `system("echo %USERNAME%")`; print ("\nCURRENT
|> WINDOWS USER:\n" + $WIN_Username);
|
|You can get to environment variables through $ENV in perl, so the above
|could be changed to string $WIN_Username = $ENV{'username'} and you
|could avoid the problem altogether.

Hi Niklas

We actually have to perform quite a few other commands after this one so
doing it in mel is necessary, however luckily we are able to use mapped
drives here too which doesn't display the error.

Thanks for your help.

|
|/Niklas
|--
|Swiss International | www.swiss.se

On 4 Jul 2006 01:12:56 -0000, Dylan Penhale <dylanpenhale@(email surpressed)> wrote:

|> Custom Mel:
|>
|> //print windows username
|> string $WIN_Username = `system("echo %USERNAME%")`; print ("\nCURRENT
|> WINDOWS USER:\n" + $WIN_Username);
|
|You can get to environment variables through $ENV in perl, so the above
|could be changed to string $WIN_Username = $ENV{'username'} and you
|could avoid the problem altogether.

Hi Niklas

We actually have to perform quite a few other commands after this one so
doing it in mel is necessary, however luckily we are able to use mapped
drives here too which doesn't display the error.

Hi Dylan,

sorry, it says right there it's MEL but I just assumed it was Perl! :)

However, couldn't you use the equivalent getenv('USERNAME') in MEL and
avoid the
system call?

/Niklas
--
Swiss International | www.swiss.se

Niklas Aldergren wrote:

However, couldn't you use the equivalent getenv('USERNAME') in MEL and
avoid the system call?

	Yes, but I think the 'echo' was just an inert example to show
	the problem; he has other external programs he wants to run.

Dylan wrote:

As we still use mapped drives here this isn't a problem for us as such.

	Dylan, I know you're familiar with my general warning about
	drive letters, and are probably using the below NET USE technique
	to make it work for you.

	But for the group's sake:
	http://www.seriss.com/rush-current/rush/rush-td-faq.html#TDFAQ-UNC

	Even Microsoft warns against the use of drive letters in multiuser
	contexts such as commands run from services like telnet, rush, rsh:
	http://support.microsoft.com/kb/180362/en-us
	..Rushd is (usually) configured to run as a service.

	One thing you can do to make sure drives are mapped is to hack
	'NET USE' commands into the render scripts just before the renderer
	is invoked, in case the users left drive mapped paths in their scene
	files, eg:

   # IF X: DRIVE ISN'T MAPPED, TRY TO MAP IT
   #    The '< nul' gets you past any 'Y/N' prompts from 'net use'..
   #
   if ( ! -d "x:/" )
       { system('net use x: \\yourserver\jobs /persistent:yes < nul'); }

   # YOUR RENDER COMMANDS HERE
   system("Render -r sw ..");

	This technique is mentioned in these older articles:
	http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+1222+1221+1222+1223+1224+1236+1237+1238+1244+1246
	http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+539
	http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-view+893+887+889+893

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

** NOTE:
**	I will be on vacation July 11th through July 20th.
**	During that time, orders and email response may take over 24 hours.
**

Dylan Penhale wrote:

CURRENT WINDOWS USER:
'\\na.fuel\share\projects\q\q_s245\q_245_176\setups\maya'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
netrender

Has anyone seen this before? It seems that the working directory is incorrect but eventually the command works when it Defaults to the windows directory. I'm wondering if it's to do with the direction of the slashes, or if the working directory needs to be set elsewhere?

	It's not the slashes, it's just DOS doesn't like the current working
	directory to be a UNC path.

	Indeed it's mostly a warning; the command will run anyway.
	But it does change the current directory to the C:\ windows directory
	before running the command.

	Microsoft explains this error best:
	http://support.microsoft.com/?kbid=156276

	You can see a similar error pretty easily in DOS by typing:

cd \\some\unc\path

	..which fails, where as:

dir \\some\unc\path

	..works fine.

	No other programming language or Windows shell scripting language
	suffers from this problem; it's only when DOS becomes involved,
	ie. when you use functions like system() or back-ticks.

	According to the above Microsoft page, there's a registry tweak
	to "fix" this. And there's something about 'Obtain the updated Cmd.exe',
	though I'm not sure if I can believe them, as they say this was fixed
	in WinNT 4.0, yet it 'Applies To' just about every release of windows
	since then, and none of them have this fix either. In fact, they forgot
	one; it applies to Windows 2000 Professional as well.


--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)

** NOTE:
**	I will be on vacation July 11th through July 20th.
**	During that time, orders and email response may take over 24 hours.
**

Greg Ercolano wrote:

Dylan Penhale wrote:
    Microsoft explains this error best:
    http://support.microsoft.com/?kbid=156276
[..]
    According to the above Microsoft page, there's a registry tweak
    to "fix" this.

	BTW, I just tried the above registry tweak, and it does
	prevent the warning, and does allow DOS to open up in a UNC directory.

	Here's a simple way to test for the problem with a one liner perl script.
	On my Win2K machine, //meade/net/tmp/scenes is a valid UNC path to a directory
	full of Maya scene files:

perl -e "chdir('//meade/net/tmp/scenes'); system('cmd /c dir');"

	When I run that command *without* the reg tweak, that command prints
	the warning, and shows a directory listing of the c:\winnt drive:

WITHOUT REG TWEAK
-----------------
C:\>perl -e "chdir('//meade/net/tmp/scenes'); system('cmd /c dir');"

CMD.EXE was started with '\\meade\net\tmp\scenes' as the current directory path.  UNC paths <<
are not supported.  Defaulting to Windows directory.                                        <<

 Volume in drive C has no label.
 Volume Serial Number is B44F-0FBA

 Directory of C:\WINNT                       <-- directory listing of C:\WINNT..

06/12/2006  01:16a      <DIR>          .
06/12/2006  01:16a      <DIR>          ..
[..]


	If I run the same command *with* the reg tweak applied, no warning
	is displayed, and it does in fact show a directory listing of the
	UNC directory, as one would expect:

REG TWEAK APPLIED
-----------------
C:\>perl -e "chdir('//meade/net/tmp/scenes'); system('cmd /c dir');"
 Volume in drive \\meade\net is net
 Volume Serial Number is 0453-0174

 Directory of \\meade\net\tmp\scenes                      <-- correct listing

06/09/2006  12:22p      <DIR>          .
06/30/2006  01:15a      <DIR>          ..
[..]


	However, this tweak still does *not* help DOS's own 'CD' command
	to work with UNC paths.. 'CD' still gives an error:

C:\>cd \\meade\net\tmp
'\\meade\net\tmp' is an invalid current directory path.  UNC paths are not supported.

	Obviously this reg tweak was just a stopgap for a specific user complaint.
	Whatever, Microsoft.

Thanks guys, looks like you have done all the stuff I was going to do this
morning :) 

We could live with that error I guess, but using mapped drives solves this
error for us in this case so I think we will use it like that for now. As we
still use mapped drives here this isn't a problem for us as such.

Once again a Microsoft quirk, thank fully there's a work around.

Cheers

|-----Original Message-----
|From: Greg Ercolano [mailto:erco@(email surpressed)]
|Sent: Tuesday, 4 July 2006 8:27 AM
|To: void@(email surpressed)
|Subject: Re: UNC paths are not supported when including some custom mel
|scripts
|
|[posted to rush.general]
|
|Greg Ercolano wrote:
|> Dylan Penhale wrote:
|>     Microsoft explains this error best:
|>     http://support.microsoft.com/?kbid=156276
|> [..]
|>     According to the above Microsoft page, there's a registry tweak
|>     to "fix" this.
|
|	BTW, I just tried the above registry tweak, and it does
|	prevent the warning, and does allow DOS to open up in a UNC directory.
|
|	Here's a simple way to test for the problem with a one liner perl script.
|	On my Win2K machine, //meade/net/tmp/scenes is a valid UNC path to a directory
|	full of Maya scene files:
|
|perl -e "chdir('//meade/net/tmp/scenes'); system('cmd /c dir');"
|
|	When I run that command *without* the reg tweak, that command prints
|	the warning, and shows a directory listing of the c:\winnt drive:
|
|WITHOUT REG TWEAK
|-----------------
|C:\>perl -e "chdir('//meade/net/tmp/scenes'); system('cmd /c dir');"
|
|CMD.EXE was started with '\\meade\net\tmp\scenes' as the current directory path. UNC paths <<
|are not supported.  Defaulting to Windows directory.                                       <<
|
|  Volume in drive C has no label.
|  Volume Serial Number is B44F-0FBA
|
|  Directory of C:\WINNT                       <-- directory listing of C:\WINNT..
|
|06/12/2006  01:16a      <DIR>          .
|06/12/2006  01:16a      <DIR>          ..
|[..]
|
|
|	If I run the same command *with* the reg tweak applied, no warning
|	is displayed, and it does in fact show a directory listing of the
|	UNC directory, as one would expect:
|
|REG TWEAK APPLIED
|-----------------
|C:\>perl -e "chdir('//meade/net/tmp/scenes'); system('cmd /c dir');"
|  Volume in drive \\meade\net is net
|  Volume Serial Number is 0453-0174
|
|  Directory of \\meade\net\tmp\scenes                      <-- correct listing
|
|06/09/2006  12:22p      <DIR>          .
|06/30/2006  01:15a      <DIR>          ..
|[..]
|
|
|	However, this tweak still does *not* help DOS's own 'CD' command
|	to work with UNC paths.. 'CD' still gives an error:
|
|C:\>cd \\meade\net\tmp
|'\\meade\net\tmp' is an invalid current directory path.  UNC paths are not supported.
|
|	Obviously this reg tweak was just a stopgap for a specific user complaint.
|	Whatever, Microsoft.