 |
 |
Hi James, FSL does obey the shell's umask but I understand that you're using SGE and, unfortunately, it does not copy your umask. The problem is that when sub-tasks get submitted to their remote hosts a shepherd process is started to manage execution and it is this proc's umask which is inherited by the running program. Unfortunately a umask of 022 is set by this process and, as far as I can tell*, it is hard- coded into SGE and cannot be reconfigured. I will discuss with the team here the possibilities for adding umask overrides into FSL scripts (maybe we could control it with an environment variable FSLSGEUMASK) but for the time being I'm afraid you'll need to re-design your work flow to fit around this one. Perhaps you can provide some scripts a user can run to (un)make results group shareable? Another possibility might be switching to a filesystem which supports ACLs - client and server OSs permitting. * I've looked at docs and config options with no success. My original source is this thread about umask issues on the SGE forum web site: http://gridengine.sunsource.net/ds/viewMessage.do? dsForumId=38&dsMessageId=11332 On 26 May 2009, at 23:27, James Kyle wrote: > Afternoon, > > It's been brought to my attention that some of the files that fsl > outputs do not have the permissions specified by a user's umask. > This poses a particular problem when researchers are collaborating > on a project as the permissions produced by fsl do not have group > write set. > > I'm unsure exactly where the problem occurs, but before I go > digging through the source I thought I'd ask if there is a default > location or config file where the default permissions for fsl file > output can be set? > > Cheers, > > James Kyle > -- Dave Flitney, IT Manager Oxford Centre for Functional MRI of the Brain E:[log in to unmask] W:+44-1865-222713 F:+44-1865-222717 URL: http://www.fmrib.ox.ac.uk/~flitney