Re: [Condor-users] Behaviour of Windows "copy" command?

[Matt Hope <matthew.hope@xxxxxxxxx>]

On 6/27/05, Rob Fletcher <rpf1@xxxxxxxxxx> wrote:
> Thanks Matt,
> 
> On Mon, 27 Jun 2005, Matt Hope wrote:
> 
> >
> > What does the std err and std out say. I'm guessing the executing user
> > may not have access to c:\windows\temp (or indeed other directories
> > outside the scratch dir).
> >
> 
> Yup, you're right ...
> 
> [condor@WEREWOLF terragen]$ more error.txt
> Access is denied.
> Access is denied.
> Access is denied.
> Access is denied.
> 
> [condor@WEREWOLF terragen]$ more output.txt
>        1 file(s) copied.
>        1 file(s) copied.
>        1 file(s) copied.
> c:\windows\temp\test3.txt
>        0 file(s) copied.
>        0 file(s) copied.
> The system cannot find the file specified.
>        0 file(s) copied.
> The system cannot find the file specified.
>        0 file(s) copied.
> The system cannot find the file specified.
> 
> > Plus you should be aware that it is dangerous to assume that
> > c:\condor\execute is the base of your scratch dir or that it even
> > exists. Unless you have total control over the execution environment.
> > Many machines in our pool ended up having their execute directories
> > moved to more sizable disks than c:
> 
> Indeed, the reason I was using the ENV VAR ...

I meant for the copy down a level one..

> So, now I see I don't have file access "out of the condor env", how do I
> run code which insists on having a hard coded output path.

with difficulty

> Actually, it's a basename type thing ... specified as
> 
> e.g. c:\anim\frame,10
> 
> Whereby the code creates c:\anim\frame0010 onwards ...
> 
> but... c:\anim\ must exist and I cannot subsitutue an env var or the like.

1) shoot whoever wrote the code. It won't help you but you'll feel
better and so will I.

> Hence trying to use a "known" writeable area ...
> 
> Odd that I can write to the c:\windows\temp OK, but am unable to copy from
> there back to the temp execute dir
> 
> Any ideas how to cirumvent this?

Simplest and most likely to succeed is for every machine where this
needs to run to allow access to that location for either Everyone (all
local users) or to the specific vm users (dangerous if you ever fancy
using SMP or faking the number of CPUs since it will all break)

If the installation of the program you are using is done in advance
then I would make this part of the install script. If not then you
have to rely on the goodwill of the people supplying the machines.

Alternatively you can change the users that condor runs programs as to
one that already has access (dangerous in that it won't log on to a
domain or anything like that and you end up needing to store
credentials etc etc - not a nice idea unless you control the machines
entirely and have a reasonable means of ensuring the creation of the
specific user required - condor just does the condor-reuse-vmx ones
itself.

Other options involve running sudo like commands with windows runas
but then the user name and password is going to be going around in
plain text...

There maybe third party tools on windows that can hack one directory
path to point to another but I would imagine these would have to run
as root so you have exactly the same problem.

<windows>\temp automatically has create/write/append/traverse and
execute access to just about every one but not read. Go figure...
(incidentally again c:\windows is not guaranteed to be the right
location e.g. winnt for later versions but again this is not
guaranteed. %SystemRoot% is well defined and I use it always.

Matt

Matt