Hi Neil,
I believe this behavior is caused by SGE, rather than FSL per se.
(We've encountered the same sort of problem). If anyone knows how to
"fix" SGE so that it doesn't do this, your insight would be appreciated.
cheers,
-MH
On Tue, 2012-05-15 at 14:19 +1000, Neil Killeen wrote:
> Hi
>
> we operate in shared project directories. The permissions are carefully
> arranged to so that children inherit the permissions of the parent
> directory.
>
> However, we are finding that during some feat processes, permissions
> get changed so that the result files can only be accessed by the
> creator.
>
> Is there any over permission changing in feat (and all of its friends
> that it uses).
>
> The user believes that its around the 'post stats' part of
> his process where the permissions change.
>
> Grep of $FSLDIR/bin only reveals
>
> [nkilleen@edward bin]$ grep chmod *
> bedpostx: chmod +x ${subjdir}.bedpostX/monitor
> bedpostx: chmod +x ${subjdir}.bedpostX/monitor
> bedpostx: chmod +x ${subjdir}.bedpostX/cancel
> bedpostx.orig: chmod +x ${subjdir}.bedpostX/monitor
> bedpostx.orig: chmod +x ${subjdir}.bedpostX/monitor
> bedpostx.orig: chmod +x ${subjdir}.bedpostX/cancel
> bedpostx~: chmod +x ${subjdir}.bedpostX/monitor
> bedpostx~: chmod +x ${subjdir}.bedpostX/monitor
> bedpostx~: chmod +x ${subjdir}.bedpostX/cancel
> feat_gm_prepare:chmod a+x ${OUT}.log/featseg1
> fslvbm_2_template:chmod a+x fslvbm2a
> fslvbm_2_template:chmod a+x fslvbm2b
> fslvbm_2_template:chmod +x fslvbm2c
> fslvbm_2_template:chmod a+x fslvbm2d
> fslvbm_2_template:chmod +x fslvbm2e
> fslvbm_3_proc:chmod a+x fslvbm3a
> fslvbm_3_proc:chmod a+x fslvbm3b
> randomise_parallel:chmod a+x ${ROOTNAME}.generate
> randomise_parallel:chmod +x ${DIRNAME}/${BASENAME}.defragment
>
>
> and in $FSLDIR/tcl
>
> [nkilleen@edward tcl]$ grep chmod *
> fdt.tcl: exec chmod 777 ${filebase}_script.sh
> featlib.tcl:fsl:exec "/bin/rm .flame ; touch .flame ; chmod a+x .flame" -n
> featlib.tcl~:fsl:exec "/bin/rm .flame ; touch .flame ; chmod a+x .flame" -n
>
>
> which is just adding the executable permission for all users and should not be an issue.
>
>
> I will have to try top establish precisely where it happens if this is not a 'known'
> effect.
>
> thanks
> Neil
|