1

I have a Bourne shell script which accepts single argument(text-file usually few KB in size). Essentially this script is a wrapper for scp which copies this text-file to remote server. Script does not try to scp the original file, but it either makes a hard-link or copy of this file:

#!/bin/sh

TRANSFER_FILE=/var/tmp/acc_transfer_link_$$
INPUT_FILE=$1

#  Linking is always a better option, so try it first
ln $INPUT_FILE $TRANSFER_FILE 2>/dev/null

RC=$?
if [ $RC -ne 0 ]; then
  cp $INPUT_FILE $TRANSFER_FILE
fi

Author of this script has left a comment:

Linking is always a better option, so try it first

Why is that so? Is it because copying takes slightly more time than creating a hard-link? Any other reason?

4
  • 1
    Depends on what you need. A copy means twice the space (and the time for writing the copy) but also one more redundancy in case of hard drive errors - but a redundancy on the same hard drive can only be useful in very specific failure scenarios.
    – FelixJN
    Aug 18, 2016 at 14:40
  • So after the ln or cp the script copies $TRANSFER_FILE to a femote host with scp? It would be useful to know why the temporary copy is made to begin with, is there reason to assume that the original file would be modified in the meanwhile? Unlikely for a small file, and the modification might happen during the local cp anyway...
    – ilkkachu
    Aug 18, 2016 at 15:00
  • 2
    What happens if someone naughty on the system creates symlinks for all the /var/tmp/acc_transfer_link_<pid> files to some critical file that the user running the program has rights to?
    – thrig
    Aug 18, 2016 at 15:14
  • 1
    It's hard to say anything because we don't know what happens next. Given your description, there's no apparent reason to not work directly with the original file. I wouldn't give the author of that script much credit given the glaring security hole that thrig obliquely describes — any local user can swap another file $TRANSFER_FILE under the script's nose if they get the timing right. Aug 18, 2016 at 21:28

1 Answer 1

1

It depends.

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 or /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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .