Hi Gregory,

We are addressing the issues you brought up in the following way:
> 1. Modify mps_Stage so that it never calls the subroutine Xfr_File. The
> manual promises that xfrcmd is always called as xfrcmd -f scriptfn
> xfrhost xfrport. The subroutine Xfr_File calls it with no arguments.
> By commenting out the setting of XfrCmd from the config file, I
> prevented Xfr_File from being called.
We conckuded that the basic problem was misleading documentation. To solve
this apparent circular assignment of transfer commands, we did a combination
of documentation changes and some code changes:

a) Specifying xfrcmd in the config file is *equivalent* to specifying the -x
option. The -x option calls the target program with the source file name and
the target file name as controlled by the substitution arguments.
b) The default program that gets called when -x (or equivalent) is not
specified is /opt/xrootd/utils/xfrcmd. This command is invoked as if it were
an "ftp" command. The -f argument provides the contents of the ftp command
stream, the command line contains the target host and port number.
c) To change the default use the newly added 'ftpcmd' directive in the
config file. This will cause the named program to be called in the standard
'ftp-like; way.

> 2. I had to put in an mps.scan directive (Dan Riley was right). That
> was the only way to get $Dolink set to 1 in mps_Stage. That's the only
> way to get $DoLink set to 1. (It happens in sub InPlace().)
Correct. We decided that this was a documentation deficiency. The rationale
here is that if the file is being placed outside the managed environment
(i.e., the list of places MigrPurg will look for files), then it shouldn't
not be placed in the cache. Unmanaged files only fill up the cache because
there is no one to get rid of them. However, if you really want the file in
the cache. the -f option of mps_Stage will force the file into the given
filesystem and create the link.

> I also noticed that the fix I made to the config parsing is still not
> quite good enough. Stripping the white space off $val has to happen
> before the splits, since we are splitting on white space. So it
> probably should be:
Bill Weeks came up with a 99% solution that works for 100% of the practical

Finally, we also changed the the search order where perl modules will be
found. This is now done at run-time. The first place will be the place where
the invoked command exists. The change proved to be more complicated than we
thought because of various Perl odditities. This does not solve the problem
if Perl is installed in some other locatation than /usr/local/bin. I don't
see any other solution for this expect to have the  'configure' script
change the first line of the file.

These changes should be included in the next release.