Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

loadRegistry() with modified working directory #60

Closed
surmann opened this issue Dec 3, 2014 · 1 comment
Closed

loadRegistry() with modified working directory #60

surmann opened this issue Dec 3, 2014 · 1 comment
Labels

Comments

@surmann
Copy link
Contributor

surmann commented Dec 3, 2014

Hallo @ALL,

I submitted a job in linux with the server working directory /home/<name>/working. This directory is available in Windows as H:\working.
If I load the registry in windows during the running job with loadRegistry("name", getwd()), BatchJobs will load the registry and change the working directory immediately. This results logically in an error for unsubmitted jobs on the linux machine.

Possible solution:
Show a message in loadRegistry() which will ask the user if she or he really wants to change the working directory.
Add a sentence to the documentation to describe this behaviour which enables the user to realise this problem.

Alternative idea:
Save two working directories. The first is the working directory in which the script started and needs a special function or option to be changed. The second working directory is the current one, in which the user works with the registry.

Regards,
Dirk

@mllg
Copy link
Member

mllg commented Feb 9, 2015

If I load the registry in windows during the running job with loadRegistry("name", getwd()), BatchJobs will load the registry and change the working directory immediately. This results logically in an error for unsubmitted jobs on the linux machine.

Why do you not simply drop the 2nd argument for loadRegistry? If it is missing, BJ will not touch it. But IMHO the major problem in your setup is the file.dir. I've added a note in b51dae9, but besides that I don't think we can do anything about it.

Did you consider using rsync and do your interim analyses on the local copy of the file dir?

@mllg mllg added the wontfix label Feb 9, 2015
@surmann surmann closed this as completed Feb 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants