Bugzilla – Bug 5829
RFT issues DCAU commands regardless of server support
Last modified: 2008-02-07 11:10:31
You need to
before you can comment on or make changes to this bug.
When contacting the source server (and probably the destination server as
well), RFT issues the "dcau N" or "dcau A" command regardless of whether the
server supports it or not. This can result in an immediate error and aborted
Error:Unable to set transfer optionsServer refused performing the request.
Custom message: (error code 1) [Nested exception message: Custom message:
Unexpected reply: 500 'dcau N': command not understood] [Caused by: Server
refused performing the request. Custom message: (error code 1) [Nested
exception message: Custom message: Unexpected reply: 500 'dcau N': command not
globus-url-copy, on the other hand, is smart enough not to issue the "dcau N"
if the option -nodcau is specified and the server does not report 'DCAU' in the
output of the 'FEAT' 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.
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.
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'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.
There's limited development effort in RFT at the moment for
various reasons. Would you be willing to provide a patch?
I'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?
cvs co -r globus_4_0_branch 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
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
The latter command fails with (the last few lines):
Checking out cvs tree gt4.
Updating CVS checkout of
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, <TAG>
In the log file I see quite a few reported CVS conflicts, like:
cvs update: move away
it is in the way
(In reply to comment #6)
> 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:
Unfortunately, this is not sufficient. See the original problem report above
which describes the unwanted consequences of turning off DCAU in RFT.
ah.. I see it now. Let me see if I can fix it real quick.
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
(In reply to comment #10)
> 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
Still no luck:
Trying to make bundle gt4-rft
Installing gt4-rft to /tmp/gt4-rft using flavor gcc32dbg, flags .
gpt-build ====> CHECKING BUILD DEPENDENCIES FOR globus_database_common
ERROR: The following packages are missing
Package globus_database_common-ANY-src is missing
Died at /tmp/gt4-rft/sbin/gpt-build line 420.
ERROR: Building of gt4-rft failed.
Sorry for not testing it first Jan. The installation command also needs
--deps, or it won'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.