Bug 3602 - Relative stdout/err paths should be relative to <directory> not ${GLOBUS_USER_HOME}
: Relative stdout/err paths should be relative to <directory> not ${GLOBUS_USER...
wsrf managed execution job service
: 4.0.0
: PC Linux
: P1 blocker
: 4.0.1
Assigned To:
  Show dependency treegraph
Reported: 2005-07-27 10:10 by
Modified: 2005-07-28 14:42 (History)



You need to log in before you can comment on or make changes to this bug.

Description From 2005-07-27 10:10:16
The stdout and stderr paths need to be resolved before being handed to the
resource manager adapter scripts because they are used to set RPs.  Currently if
they are relative paths they are being resolved with respect to the 
GLOBUS_USER_HOME substitution variable.  These really need to be resolved with
respect to the directory element value.  As a consequence, the directory value
needs to be resolved to an absolute path as well before being handed to the
adapter scripts.  Therefore the directory value should be resolved with respect
to GLOBUS_USER_HOME if it is relative.
------- Comment #1 From 2005-07-27 17:10:16 -------
I committed the fix to globus_4_0_branch as well as an updated relative
directory scheduler test (submit208a-c).  The updated test uses the randomly
generated test directory instead of GLOBUS_USER_HOME for <directory>, improving
the effectiveness of the test.

Associated updates to the trunk will happen soon, at which time I'll resolve the
------- Comment #2 From 2005-07-28 12:12:17 -------
Fixes in the trunk as well, now.
------- Comment #3 From 2005-07-28 14:42:27 -------
Also just added a new test case that makes sure subsittutions are being handled
correctly for the directory element before and after prepending
GLOBUS_USER_HOME.  The original fix I had comitted would see "^${.+}" as a
relative directory because the substitutions weren't being resolved before hand
and a leading dollar sign is obvioulsy not an absolute path prefix.