Running jobs as real user and extra_file_path
Hi everyone, I just wanted to ask how the extra_file_path is handled in case of job running as the real user since the file_path is only writable by the galaxy user. Any clue? Thanks, L-A
On Apr 25, 2012, at 9:39 AM, Louise-Amélie Schmitt wrote:
Hi everyone,
I just wanted to ask how the extra_file_path is handled in case of job running as the real user since the file_path is only writable by the galaxy user. Any clue?
Hi L-A, There are actually two dataset attributes for accessing the extra files directory, 'files_path' and 'extra_files_path'. 'extra_files_path' always points to the real path under the directory specified in the config file's 'file_path' option and should be used when providing a dataset's extra files directory as the input to a tool. 'files_path' points at the location that should be written to when used in a job so that the job's finish method can find the output files. This will be under the job_working_directory and thus writable by the actual user. So any tool outputs that use the extra files directory should use the output's 'files_path' attribute. Sorry for this confusion. There was talk some time ago about merging both attributes to work correctly in all cases, but this was never done. --nate
Thanks, L-A ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:
On Mon, Apr 30, 2012 at 4:47 PM, Nate Coraor <nate@bx.psu.edu> wrote:
On Apr 25, 2012, at 9:39 AM, Louise-Amélie Schmitt wrote:
Hi everyone,
I just wanted to ask how the extra_file_path is handled in case of job running as the real user since the file_path is only writable by the galaxy user. Any clue?
Hi L-A,
There are actually two dataset attributes for accessing the extra files directory, 'files_path' and 'extra_files_path'.
'extra_files_path' always points to the real path under the directory specified in the config file's 'file_path' option and should be used when providing a dataset's extra files directory as the input to a tool.
'files_path' points at the location that should be written to when used in a job so that the job's finish method can find the output files. This will be under the job_working_directory and thus writable by the actual user. So any tool outputs that use the extra files directory should use the output's 'files_path' attribute.
Sorry for this confusion. There was talk some time ago about merging both attributes to work correctly in all cases, but this was never done.
--nate
Is this still the case? I'm guessing this is what Raj was alluding to with the BLAST+ wrapper for makeblastdb which creates a composite datatype as its output: http://lists.bx.psu.edu/pipermail/galaxy-dev/2013-March/013887.html If I'm using a single Linux/Unix galaxy user this doens't matter does it? Thanks, Peter
On Wed, Mar 20, 2013 at 3:51 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Mon, Apr 30, 2012 at 4:47 PM, Nate Coraor <nate@bx.psu.edu> wrote:
On Apr 25, 2012, at 9:39 AM, Louise-Amélie Schmitt wrote:
Hi everyone,
I just wanted to ask how the extra_file_path is handled in case of job running as the real user since the file_path is only writable by the galaxy user. Any clue?
Hi L-A,
There are actually two dataset attributes for accessing the extra files directory, 'files_path' and 'extra_files_path'.
'extra_files_path' always points to the real path under the directory specified in the config file's 'file_path' option and should be used when providing a dataset's extra files directory as the input to a tool.
'files_path' points at the location that should be written to when used in a job so that the job's finish method can find the output files. This will be under the job_working_directory and thus writable by the actual user. So any tool outputs that use the extra files directory should use the output's 'files_path' attribute.
Sorry for this confusion. There was talk some time ago about merging both attributes to work correctly in all cases, but this was never done.
--nate
Is this still the case?
I'm guessing this is what Raj was alluding to with the BLAST+ wrapper for makeblastdb which creates a composite datatype as its output: http://lists.bx.psu.edu/pipermail/galaxy-dev/2013-March/013887.html
If I'm using a single Linux/Unix galaxy user this doens't matter does it?
Thanks,
Peter
Some years later, this question has been resurrected as https://github.com/galaxy-iuc/standards/issues/40 Peter
participants (3)
-
Louise-Amélie Schmitt -
Nate Coraor -
Peter Cock