So, now my question is, which files have the wrong permissions? I'll try to fix up all of them, but if you can point to some which aren't working, that would help.
Thanks, Tom On Wed, Jan 28, 2009 at 1:01 PM, Tom Scavo <[email protected]> wrote: > On Wed, Jan 28, 2009 at 1:58 PM, Tom Howe <[email protected]> wrote: > > What version of gt are you using? > > GT 4.0.8 > > Thanks for asking, Tom. > > Tom > > PS. Ignore the last paragraph below, that is, out of the box there are > no executables in $GLOBUS_LOCATION/bin that have the wrong > permissions. AFAIK, the problem occurs only when deploying a GAR > file. > > > On Sat, Jan 24, 2009 at 3:14 PM, Tom Scavo <[email protected]> wrote: > >> > >> On Sat, Jan 24, 2009 at 2:47 PM, Tom Scavo <[email protected]> wrote: > >> > After deploying a GAR file with 'globus-deploy-gar', any executables > >> > deployed in ${abs.deploy.dir}/bin do not have the correct permissions > >> > (755). Instead they end up with permissions (664). Is this a bug? > >> > >> I think I figured out what's going on. After executing > >> 'globus-deploy-gar', some of the executables in ${abs.deploy.dir}/bin > >> have the correct permissions and some do not. The ones that don't > >> have the correct permissions have incorrect EOL characters (i.e., CRLF > >> instead of LF). After correcting the faulty EOL characters in the GAR > >> and redeploying, the permissions on all files are correct. > >> > >> So it looks like the chmod task fails on files with incorrect EOL > >> characters (at least on CentOS 4.7 X86_64). Why not invoke task > >> fixcrlf before changing permissions in build-packages.xml? Let me > >> know if you want me to create a bug for this. > >> > >> By the way, this may explain why other executables in > >> $GLOBUS_LOCATION/bin have the wrong permissions. I haven't verified > >> this, however. > >> > >> Tom > > > > >
