 |
 |
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 cases. 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. Andy