I am trying to reproduce your problem, and it seems like I need to know
more about who maps the G: drive. Is this a logon script, or did you
just map it from My Computer or a 'net use' at the command line?
Also, does this problem only happen on Windows 2003 Server, or does it
happen on other Windows OS's too?
As far as fopen() or chdir() being able to handle UNC paths, that's not
it--they can handle them just fine.
The reason we convert the path to a UNC path at submit time is because
starting in (I believe) Windows 2000 SP2, drive mappings went from being
a global entity to a per-logon-session entity. For example, back in NT4
days, user Administrator could map G: to \\foo\bar and every other user
on the system would see it. Nowadays, Administrator can map all the
drives he wants and nobody can see them.
For Condor, this means that when the shadow logs your account in, the
drive mappings won't necessarily be there (they'll be there as long as
you don't log out, but we don't make any requirements about you having
to be logged in until all your jobs are done).
The one drawback to this method is that if you map some drive using
credentials other than your own, Condor can't access the share.
condor_submit checks for this case and should bomb out if you attempt it.
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}