Что происходит с данными в неопрашиваемых сокетах дейтаграмм?

Вероятно, мне следует рассказать о ловушке сценария с жесткими ссылками. Жесткая ссылка будет просто тем же файлом с другим именем и/или другим местоположением , пока существует исходный связанный файл . Неправильно даже думать о файле как об "оригинальном" :, оба являются элементами каталога сами по себе, и оба (или более )являются равноправными узлами. Для долгоживущих -файлов это может быть благом, но если один из пары будет удален, а затем создан, даже с тем же именем и содержимым, файлы разделятся.

Предположим, вы создали жесткую ссылку /foo/myfileна /repo/myfile. Оба являются указателями на одни и те же данные файла; меняешь одно, меняется другое. Но предположим, что /repoсодержит репозиторий Git. Если вы извлекаете ветку, в которой нет myfile, /repo/myfileудаляется. В этот момент /foo/myfileстановится простой копией /repo/myfile, как в тот момент, когда другой из пары был несвязан. Легко даже не заметить, когда вы переключаетесь между ветвями, что репертуар файлов меняется, но когда вы извлекаете исходную ветвь, Git создает новый файл /repo/myfile. Если бы вы не обращали внимания, вы бы удивились, почему эти два файла теперь имеют разное содержимое, хотя это легко понять, так как отношения жесткой связи между файлами не имеют понятия об их именах. Мягкая ссылка,напротив, выжил бы в этом цикле удаления -создания.

С другой стороны, программное обеспечение, использующее жесткие ссылки, прекрасно понимает это, и Git — яркий тому пример. Git почти бесплатно клонирует репозиторий в той же файловой системе, поскольку по умолчанию использует жесткие ссылки вместо копирования файлов. Для Git жесткая ссылка является идеальным вариантом использования, потому что его объектные и пакетные файлы никогда не меняются, поэтому один клон репозитория никогда не изменит другой (. Git знает, что нельзя жестко -связывать изменяемые файлы ), любой из клонов может быть удален без каких-либо предосторожностей :нет необходимости отслеживать, какой из них является "оригиналом" и на самом деле содержат файлы :любая из жестких ссылок является равноправным партнером и " содержит" полный файл. Мягкие ссылки просто не будут работать здесь.

Другое преимущество жесткой ссылки заключается в том, что любую ссылку можно переместить, не нарушая доступа к содержимому файла. При использовании программных ссылок перемещение исходного файла делает все программные ссылки на него повисшими.

Суть в том, что во многих случаях любой тип ссылки работает одинаково хорошо, но в некоторых случаях преимущество имеет тот или иной тип. Эффективность, упомянутая во многих ответах здесь, вероятно, мало волнует современные машины и файловые системы, если только вы не очищаете файловую систему на микросхеме FLASH маленького встроенного контроллера. функциональные различия более важны и обычно диктуют технические ограничения и окончательный выбор :

• Жесткая ссылка «источник» может быть безопасно перемещена, в то время как программная ссылка сломается.
• Жесткая ссылка неотличима от файла, из которого она была связана, и файл активен до тех пор, пока активна любая из жестких ссылок; мягкая ссылка асимметрична.
• Жестко -связанный одноранговый узел выходит из связанной группы, если он удаляется и -создается повторно, но мягкая ссылка не теряет своей цели.
• Мягкая ссылка может пересекать файловые системы, а жесткая ссылка — нет.
• Мягкая ссылка может указывать на каталог, жесткая ссылка обычно не может (и практически всегда не должна ).

Кроме того, я должен отметить, что библиотечный вызов, который удаляет файл, называется unlink()не просто так! Каждая запись каталога — это всего лишь изначально единственная жесткая ссылка на свой индексный дескриптор.