Making a link is faster than copying the data, but the resulting file will have the same contents as the original, and any modifications will show in both. If that is advantage or not, depends on why the link/copy was made. Also, hard links only work within the same filesystem, so if
/var/tmp is a separate mount from the source directory, linking will not work.
But I wonder what the use case here is. If the purpose of the script is to copy the file named in
$1, why make a copy to
$TRANSFER_FILE instead of just running
scp on the original file directly? Taking a local copy first should only be necessary if there is reason to assume that the source file might be modified during the copy, and the file should not be copied in an inconsistent state. But the approach here has some problems:
1) making a local copy with
cp has the same problem: the source might also be modified during the local copy.
2) linking with
ln would be instant, but since the hard link points to the same data as the original, any process that opened the file before the link was made could still continue to modify the data.
One would either need to make sure the file is not open in another process after the link (by using something like
lsof), or make a copy and verify the consistency of the data by some application-specific method. Since neither is that simple, the usual way to do atomic modifications is to write a new copy of the file, and rename it over the old one. That way any processes that opened the file before the rename will get the old version, and any processes that opened it after the rename, will get the new version. But neither will see an incomplete copy. This has to be done when the file is modified, however, not in the program reading the file.