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?

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

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

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, <TAG>
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';
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:
> 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.

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
compile-globus_java_ws_core_common-ANY-pgm

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.