Intereting Posts

преимущества жесткой ссылки файла над копией файла

У меня есть сценарий оболочки Bourne, который принимает один аргумент (текстовый файл обычно имеет размер в несколько килобайт). По сути этот скрипт является оболочкой для scp которая копирует этот текстовый файл на удаленный сервер. Скрипт не пытается scp исходный файл, но он либо делает жесткую ссылку, либо копирует этот файл:

 #!/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 

Автор этого скрипта оставил комментарий:

Связывание всегда лучше, поэтому попробуйте сначала

Почему это так? Это потому, что копирование занимает немного больше времени, чем создание жесткой ссылки? Любая другая причина?

Это зависит.

Создание ссылки происходит быстрее, чем копирование данных, но полученный файл будет иметь то же содержимое, что и оригинал, и любые изменения будут отображаться в обоих. Если это преимущество или нет, зависит от того, почему была создана ссылка / копия. Кроме того, жесткие ссылки работают только в одной и той же файловой системе, поэтому если /var или /var/tmp является отдельным монтированием из исходного каталога, ссылка не будет работать.


Но мне интересно, что здесь используется. Если целью сценария является копирование файла с именем $1 , зачем делать копию в $TRANSFER_FILE а не просто запускать scp в исходном файле напрямую? Первое использование локальной копии должно быть необходимо только в том случае, если есть основания предполагать, что исходный файл может быть изменен во время копирования, и файл не должен копироваться в несогласованном состоянии. Но здесь есть некоторые проблемы:

1) создание локальной копии с cp имеет ту же проблему: источник также может быть изменен во время локальной копии. 2) связь с ln будет мгновенной, но поскольку жесткая ссылка указывает на те же данные, что и оригинал, любой процесс, который открыл файл до того, как была сделана ссылка, все равно может продолжать изменять данные.

Нужно либо убедиться, что файл не открыт в другом процессе после ссылки (используя что-то вроде lsof ), либо сделать копию и проверить согласованность данных с помощью какого-то конкретного метода. Поскольку это не так просто, обычный способ сделать атомные модификации – написать новую копию файла и переименовать его поверх старого. Таким образом, все процессы, открывшие файл перед переименованием, получат старую версию, и любые процессы, открывшие ее после переименования, получат новую версию. Но никто не увидит неполную копию. Это необходимо сделать, если файл изменен, но не в программе, читающей файл.