System produces error such as "cannot find file" when you try to execute transfer.
Suggestion:
If the system gives an error like this, it's possible that the first line of transfer doesn't specify the correct path to perl for your system. Use the command "which perl" or, on some systems, "whence perl" to find the correct path and verify that the first line is correct. If the line is not correct, modify the line appropriately.
This problem may also occur if transfer is not in your PATH. For example, if the current directory "." is not in your PATH and you are trying to execute transfer from your current directory, you will need to precede transfer with "./" on the command line, as in the example
./transfer incr info_file
The current directory "." is not in the default PATH on some systems such as Redhat Linux, for example, since having "." in your PATH is a security hazard.
Not all files on the exclusion list are excluded.
Suggestion:
Make sure that all entries in the exclude list are separated by commas.
Cannot use the home directory of the remote account as the remote root from an information file.
Suggestion:
If you want to use the home directory of the remote account as the remote root using an information file, you must specify the remote root as
If the value for remote_root is blank in an information file, transfer will not read the information fields properly. However, a blank value for the remote root should work fine when entered interactively.
The script consistently transfers a certain number of files but fails on additional files.
Suggestion:
Your connection may be timing out. If you are using a connect script to establish a network connection, the script may not be keeping the connection alive. The script needs to be modified to keep the connection alive.
Alternatively, applications which periodically send queries over the network will keep the connection alive. For example, when Netscape is configured to check for email sufficiently often, it can keep connections alive. Emacs will also act in this manner. A properly configured Xbiff might serve this purpose too.
However, I do not suggest that you consistently rely on one of these applications to keep your machine connected. That is not their purpose and each of these applications has more overhead than is reasonable for the task of keeping your machine connected. Having your connect script periodically send a single ping to a reliable remote machine is a better solution and there are undoubtedly many other more elegant solutions. I recommend that you modify your connect script appropriately if you happen to encounter this problem.