Dylan Penhale wrote:
Our submit script checks all XP machines have a set of drives mapped. If the
drives are unavailable or not there then it maps them. In the script we also
output the command "net use" so we can see what is mapped.
However, sometimes when the mapped drives are unavailable the script can't
remap them.
Then go into a 'retry loop', repeating the map operation until it
succeeds (with a 'sleep(10);' in between..).
After some number of retries considered 'too long to wait', you
could either requeue the frame, or fail it.
Where does rush map these drives?
Rush does NOT map drives, ever.
[UPDATE 07/18/2014: Actually in Rush 103.x, the new rush/etc/path_convert file ]
[can be used to have Rush create drive mappings. This was not the case in 2006 ]
[when this article was written. ]
Someone likely tweaked the submit scripts to include a 'net use x: \\some\path'
commands into the script before the renderer is invoked.
So look in the submit script, in the 'if ( $ARGV[0] eq "-render" )' section
of the code.
The best way to include net use commands into a submit script is to bracket
the 'net use' command with an if() or while() statement to test if the drive
is already mapped, eg:
# DRIVE MAP CHECK
if ( ! -d "x:/" )
{
{
my $cmd = 'net use x: /delete < nul';
print "X: NOT MAPPED.. FORCING UNMAP FIRST '".$cmd."'\n";
system($cmd);
}
{
my $cmd = "net use x: \\\\mayaserver\\jobs /persistent:yes < nul";
print "REMAPPING USING '".$cmd."'\n";
system($cmd);
}
# system("dir x:"); # debugging
}
The '< nul' will at least get you past the 'Y/N' prompt,
which one apparently can't disable, according to 'net use /?'.
This is really starting to hurt my brain.
Don't say I didn't warn you ;)
http://www.seriss.com/rush-current/rush/rush-td-faq.html#TDFAQ-UNC
[UPDATE 07/18/14: While the issues cited in the above link are ]
[still relevant, many customers seem to reliably run OK with ]
[drive maps enabled with code like the above in the render script ]
[to force them to be enabled. ]
I'm thinking of having to delete all
mapped drives and remap them at the start of each frame just to have fail
safe maps.
Do you have some of the errors you're getting back from the OS
regarding the failed drive map commands?
That would help, as often one can search for the OS error on
support.microsoft.com's knowledgebase, and find solutions or
at very least causes.
Look at the event log on your server too for errors; possibly the server
has run out of SMB licenses; some file servers, such as Windows based file
servers, license each drive map connection, and will deny connections if
there are 'more than you're licensed to use'.
Many users are now using UNC paths but some old scripts still use
mapped drives so we still need to keep them.
See if you can identify why the old scripts 'need' drive maps,
and try to rework them to use UNC.
One of the very few reasons I've found I 'need' drive maps is when
I'm in a DOS shell, and want to 'cd' to a network drive;
one can't 'cd' to UNC paths; DOS is old and crappy, and has legacy ties
to the concept of drive letters internally, to support old 16bit apps.
Regular shells (like tcsh, sh, perl, python) have no problems with this,
only DOS.
So unless you're somehow dependent on DOS batch scripts that need to 'chdir'
to drive maps, you should be able to get away from drive letters. I'd be
curious to hear if there are other reasons that might be stuck with drive
letters (besides the fact that drive letters 'might' be in the scene files)
[UPDATE 08/16/07: the drive map example was modified 08/16/07 to include ]
[the /delete flag which ensures a 'disabled connection' is deleted and ]
[then recreated.]
--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)
|