Я имею в виду, что происходит, когда какой-то процесс хочет прочитать символическую ссылку? Что происходит, когда что-то меняет символическую ссылку в процессе чтения или даже записи?
Например: у меня есть 2 огромных, похожих файла 100G /mnt/1и /mnt/2. /mnt/1доступно через символическую ссылку /home/user/file. Некоторая программа Aначинает читать /home/user/file. И через некоторое время что-то меняет ссылку с /mnt/1на /mnt/2, но Aвсе равно читает файл.
Программа кеширует абсолютный путь?
Будет ли сбой и ошибка, потому что символическая ссылка была изменена или будет работать нормально, как будто ничего не произошло?
Будет ли он отличаться в случае, если /home/user/fileон связан с блочным устройством (например, 2 реплицированных диска iscsi)?
filesystems
symlink
порыв
источник
источник
Символическая ссылка представляет собой небольшой файл , который содержит местоположение (т.е. пути и имя файла) целевой файл, с флагом в записи каталога , указывающей , что это символическое.
Когда вы открываете символическую ссылку, ОС будет следовать местоположению, чтобы найти целевой файл. Если цель сама является символической ссылкой, она также следует своему расположению (1) (2), пока местоположение не укажет на файл, который не является символической ссылкой (назовем его FinalFile ). Затем операционная система получает инод в FinalFile (индексный дескриптор содержит метаданные , как изменения времени и имеет также указатель на данные файла). Наконец открывается индекс FinalFile . Отныне процесс использует этот индекс для чтения / записи в файл. В результате изменение имени или пути символической ссылки, удаление символической ссылки, изменение пути или имени FinalFile или даже удаление FinalFile(3) не влияет на процесс; это все еще читает из того же самого inode.
В большинстве случаев операции с данными файла над символической ссылкой будут влиять на FinalFile (например, чтение и запись в символическую ссылку будут считывать / записывать в FinalFile ), но существуют исключения:
readlink()системный вызов считывает содержимое самой символической ссылки.С другой стороны, операции с метаданными файла (например, переименование или удаление) обычно влияют на символическую ссылку. Но здесь есть и исключения:
lstat()системный вызов похожstat(), за исключением того, что он возвращает информацию о самой символической ссылке, а не о FinalFile (2).(1) Существует ограничение на количество уровней, и все становится немного сложнее, если местоположение в символической ссылке является относительным путем.
(2) Прочитайте символическую ссылку (7): обработка символьных ссылок для более подробной информации.
man 7 symlink(3) Команда
rmилиunlink()системный вызов физически не удаляют файл. Он удаляет запись каталога, которая указывает на индекс файла. Сам файл удаляется только если как а) нет больше записей каталога (жесткие ссылки) , которые относятся к его инода и б) ни один процесс не имеет файл открыт.источник
Это почти прозрачно для Linux, и оно гораздо больше связано с используемой файловой системой, чем с операционной системой.
Это не обычный файл или очень маленький файл, потому что вы не можете создать рабочую символьную ссылку в разделе VFAT, например, просто скопировав саму символическую ссылку, потому что она записывается непосредственно файловой системой.
Разница в символической ссылке на жесткую ссылку заключается в том, что назначение - это жесткая ссылка, а не привязка к секторам данных, как это делает жесткая ссылка.
Пример:
Тест 1:
Это создаст жесткую ссылку file.txt, указывающую на сектора от 10 до 20 * (* цифры только для пояснения).
Тест 2:
Что теперь, если?
Это создало hardlink file_2.txt, указывающий на секторы с 10 по 20 (то же самое, что и у file.txt), поэтому, если вы удалите file.txt, сектора с 10 по 20 все еще зарезервированы, и вы сможете увидеть данные внутри file_2.txt ... , (file.txt и file_2.txt похожи на оригиналы)
Тест 3:
Указанная символическая ссылка file_sym.txt на жесткую ссылку file.txt, поэтому при попытке доступа к file_sym.txt вы увидите file.txt, но если вы удалите file.txt, file_sym больше не найдет цель.
Они управляются файловой системой, например, модулями ext4 для linux (или если она скомпилирована в ядре), не имеет значения, используете ли вы Linux или другой Unix.
источник