<?xml version="1.0" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugzilla.globus.org/bugzilla/bugzilla.dtd">

<bugzilla version="3.2.3"
          urlbase="http://bugzilla.globus.org/bugzilla/"
          maintainer="bacon@mcs.anl.gov"
>

    <bug>
          <bug_id>5829</bug_id>
          
          <creation_ts>2008-02-05 03:56</creation_ts>
          <short_desc>RFT issues DCAU commands regardless of server support</short_desc>
          <delta_ts>2008-02-07 11:10:31</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>RFT</product>
          <component>RFT</component>
          <version>4.0.5</version>
          <rep_platform>PC</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>NEW</bug_status>
          
          
          
          
          
          <priority>P3</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Jan Ploski">Jan.Ploski@offis.de</reporter>
          <assigned_to name="Ravi Madduri">madduri@mcs.anl.gov</assigned_to>
          <cc>annc@isi.edu</cc>
    
    <cc>rft-dev@globus.org</cc>
    
    <cc>schuler@isi.edu</cc>

      

      
          <long_desc isprivate="0">
            <who name="Jan Ploski">Jan.Ploski@offis.de</who>
            <bug_when>2008-02-05 03:56:20</bug_when>
            <thetext>When contacting the source server (and probably the destination server as well), RFT issues the &quot;dcau N&quot; or &quot;dcau A&quot; command regardless of whether the server supports it or not. This can result in an immediate error and aborted transfer:

Error:Unable to set transfer optionsServer refused performing the request. Custom message:  (error code 1) [Nested exception message:  Custom message: Unexpected reply: 500 &apos;dcau N&apos;: command not understood] [Caused by: Server refused performing the request. Custom message:  (error code 1) [Nested exception message:  Custom message: Unexpected reply: 500 &apos;dcau N&apos;: command not understood]]

globus-url-copy, on the other hand, is smart enough not to issue the &quot;dcau N&quot; if the option -nodcau is specified and the server does not report &apos;DCAU&apos; in the output of the &apos;FEAT&apos; command.

The server which is causing problems with RFT is the dCache GSI FTP Door. I suspect that this is what makes staging from/to dCache with WS GRAM impossible.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Martin Feller">feller@mcs.anl.gov</who>
            <bug_when>2008-02-05 11:17:44</bug_when>
            <thetext>Good point. Sorry, I forgot that when i answered on your e-mail
in this matter.
I once tried to get RFT running with dCache and kept stuck
because of this. It seems to be the underlying
GridFTPClient.setDataChannelAuthentication() in jglobus which is
responsible for this.

If i remember right then RFT also uses the MLST command to be able to
set file permissions on the destination side like they are on the
source side after transferring files. This may not be supported
by other GridFTP implementations too.
But this is something you can make RFT ignore by setting the flag
ignoreFilePermErr in the rftOptions element of a transfer description.
(Note that globus-url-copy does not adjust file permissions on the 
server-side after a transfer)

RFT will be re-written and i added that topic to the discussion.
I think support for other GridFTP implementations is planned.
Plans are that Gram4 will use that new RFT then for staging purposes.

Rob and Ann (on CC) may add more details about what and when.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Jan Ploski">Jan.Ploski@offis.de</who>
            <bug_when>2008-02-05 11:51:48</bug_when>
            <thetext>JGlobus is not to blame - we also use JGlobus in our own GridFTP client and we managed to carefully avoid all the dCache show-stoppers. (MLSD is definitely not supported by dCache; I don&apos;t know about MLST.)

We have gathered quite a list of observed dCache deficiencies in our project (most related to the handling of file attributes and ownership) which we will be forwarding to the German Grid support project for consideration. However, the main point is that even the current version of dCache could work for file staging with some slight adjustments in RFT.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Martin Feller">feller@mcs.anl.gov</who>
            <bug_when>2008-02-05 12:09:48</bug_when>
            <thetext>There&apos;s limited development effort in RFT at the moment for
various reasons. Would you be willing to provide a patch?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Jan Ploski">Jan.Ploski@offis.de</who>
            <bug_when>2008-02-06 07:05:09</bug_when>
            <thetext>I&apos;d provide a patch if I could quickly set up a development environment (in Eclipse) for modifying and debugging the RFT code. How easy is that?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Charles Bacon">bacon@mcs.anl.gov</who>
            <bug_when>2008-02-06 09:25:57</bug_when>
            <thetext>export CVSROOT=:pserver:anonymous@cvs.globus.org:/home/globdev/CVS/globus-packages
cvs co -r globus_4_0_branch packaging
cd packaging
./make-packages.pl --bundles=gt4-rft --deps --skippackage --skipbundle

You then have a checkout of RFT and its dependencies under packaging/source-trees.  You can then build your modified RFT by running:
./make-packages.pl --bundles=gt4-rft --install=/path/to/install</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Ravi Madduri">madduri@mcs.anl.gov</who>
            <bug_when>2008-02-06 11:38:28</bug_when>
            <thetext>In RFTOptionsType there is a option you can set to turn off DCAU. IF you are using rft command line client you can see the documentation here to set it to appropriate value: http://www.globus.org/toolkit/docs/4.0/data/rft/rn01re01.html</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Jan Ploski">Jan.Ploski@offis.de</who>
            <bug_when>2008-02-06 11:39:42</bug_when>
            <thetext>The latter command fails with (the last few lines):

Checking out cvs tree gt4.
Updating CVS checkout of :pserver:anonymous@cvs.globus.org:/home/globdev/CVS/globus-packages
Queueing ws-delegation on update command.
Queueing ws-mds on update command.
Queueing ws-transfer on update command.
Queueing wsrf on update command.
Logging to /home/jploski/workspace-3.2/packaging/./log-output/cvs-logs/gt4.log
ERROR: Trouble with cvs up on tree gt4. at ./make-packages.pl line 900, &lt;TAG&gt; line 14.

In the log file I see quite a few reported CVS conflicts, like:
cvs update: move away `ws-mds/servicegroup/schema/inmemorysg/InMemoryServiceGroupEntry_bindings.wsdl&apos;; it is in the way</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Jan Ploski">Jan.Ploski@offis.de</who>
            <bug_when>2008-02-06 11:46:41</bug_when>
            <thetext>(In reply to comment #6)
&gt; In RFTOptionsType there is a option you can set to turn off DCAU. IF you are
&gt; using rft command line client you can see the documentation here to set it to
&gt; appropriate value:
&gt; http://www.globus.org/toolkit/docs/4.0/data/rft/rn01re01.html

Unfortunately, this is not sufficient. See the original problem report above which describes the unwanted consequences of turning off DCAU in RFT.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Ravi Madduri">madduri@mcs.anl.gov</who>
            <bug_when>2008-02-06 11:50:01</bug_when>
            <thetext>ah.. I see it now. Let me see if I can fix it real quick.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Charles Bacon">bacon@mcs.anl.gov</who>
            <bug_when>2008-02-06 14:12:09</bug_when>
            <thetext>Sorry, the latter command should read:
./make-packages.pl --bundles=gt4-rft -n --install=/path/to/install

the -n turns off cvs updates (and the conflict</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Jan Ploski">Jan.Ploski@offis.de</who>
            <bug_when>2008-02-07 04:15:42</bug_when>
            <thetext>(In reply to comment #10)
&gt; Sorry, the latter command should read:
&gt; ./make-packages.pl --bundles=gt4-rft -n --install=/path/to/install
&gt; 
&gt; the -n turns off cvs updates (and the conflict

Still no luck:

Trying to make bundle gt4-rft
Installing gt4-rft to /tmp/gt4-rft using flavor gcc32dbg, flags .
gpt-build ====&gt; CHECKING BUILD DEPENDENCIES FOR globus_database_common
ERROR: The following packages are missing
Package globus_database_common-ANY-src is missing compile-globus_java_ws_core_common-ANY-pgm

Died at /tmp/gt4-rft/sbin/gpt-build line 420.
ERROR: Building of gt4-rft failed.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who name="Charles Bacon">bacon@mcs.anl.gov</who>
            <bug_when>2008-02-07 11:10:31</bug_when>
            <thetext>Sorry for not testing it first Jan.  The installation command also needs --deps, or it won&apos;t install the required software.

My usual method is to just use fait_accompli/installer.sh to get a full toolkit installer, I was just trying to save time by only having you check-out/build the RFT component.</thetext>
          </long_desc>
      
      

    </bug>

</bugzilla>