Я отвечу на это с точки зрения пользователя * nix (в частности, Linux). Если вас интересует, как это относится к Windows, я предлагаю вам поискать учебники , например, . Это будет немного окольным путем, но я считаю, что символические ссылки или символические ссылки лучше всего объяснить вместе с жесткими ссылками и общими свойствами файловой системы в Linux.
Ссылки и файлы в Linux
Как правило, в Linux все рассматривается как файл. Каталоги - это файлы, которые содержат сопоставления от names (paths) до inode , которые являются просто уникальными идентификаторами различных объектов, находящихся в вашей системе. По сути, если я дам вам имя, например /home/gst/mydog.png, процесс доступа сначала будет смотреть в каталог / (корневой каталог ), где он найдет информацию о том, где найти home, а затем откроетэтот файл он изучит в нем, чтобы увидеть, где находится gst, и, наконец, в этом файле он попытается найти местоположение mydog.png, и в случае успеха попытайтесь сделать все, что он намеревается с ним сделать. Возвращаясь к файлам каталогов, их отображения называются links. Что приводит нас к жестким и символическим ссылкам.
Жесткие и символические ссылки
Жесткая ссылка - это просто отображение, подобное тому, которое мы обсуждали ранее. Это указывает непосредственно на определенный объект. С другой стороны, символическая ссылка не указывает непосредственно на объект. Скорее это просто сохраняет путь к объекту. Например, скажем, что я создал символическую ссылку на /home/gst/mydog.png в /home/gst/Desktop/mycat.png с os.symlink("/home/gst/mydog.png", "/home/gst/Desktop/mycat.png"). Когда я пытаюсь открыть его, имя /home/gst/Desktop/mycat.png обычно разрешается до /home/gst/mydog.png. По после символической ссылки, расположенной по адресу /home/gst/Desktop/mycat.png Я фактически (пытаюсь) получить доступ к объекту, указанному /home/gst/mydog.png.
Если я создаю жесткую ссылку (например, вызывая * 1038)*) Я просто добавляю записи в соответствующие файлы каталогов, так что конкретное имя может сопровождаться связанным объектом. Когда я создаю символическую ссылку, я создаю файл , который содержит путь к другому файлу (который может быть другой символической ссылкой).
Более конкретно на ваш вопрос, если я передам /home/gst/Desktop/mycat.png на os.readlink, он вернет /home/gst/mydog.png. Это разрешение имен также происходит при вызове функций в os с (необязательным) параметром follow_symlinks, установленным на True, однако, если он установлен на False, имя не разрешается (например, вы бы его установили)в false, если вы хотите манипулировать самой символической ссылкой, а не объектом, на который она указывает). Из документации модуля :
не следует символьным ссылкам : если follow_symlinks равно False, и последний элемент путиработать с символической ссылкой, функция будет работать с самой символической ссылкой, а не с файлом, на который указывает ссылка. (Для систем POSIX Python вызовет l... версию функции.)
Вы можете проверить, поддерживается или нет follow_symlinks на вашей платформе, используя os.supports_follow_symlinks . Если он недоступен, его использование вызовет NotImplementedError .
Зачем использовать жесткие ссылки?
На этот вопрос уже был дан ответ здесь цитата из принятого ответа:
Основным преимуществом жестких ссылок является то, что по сравнению с мягкими ссылками нет размера или потери скорости. Мягкие ссылки - это дополнительный уровень косвенности поверх обычного доступа к файлам;ядро должно разыменовать ссылку, когда вы открываете файл, и это занимает немного времени. Ссылка также занимает небольшое место на диске для хранения текста ссылки. Этих штрафов не существует с жесткими ссылками, потому что они встроены в саму структуру файловой системы.
Я бы хотел добавить, что жесткие ссылки позволяют легко создавать резервные копии файлов. Для каждого файла система ведет подсчет жестких ссылок. Как только это число достигает 0, сегмент памяти, в котором находится файл, помечается как свободный, что означает, что система в конечном итоге перезапишет его другими данными (фактически удалив предыдущий файл - что не происходит по крайней мере до тех пор, пока выполняетсяУ процесса есть открытый поток, связанный с файлом, но это уже другая история). Почему это имеет значение?
Допустим, у вас есть огромный каталог, полный файлов, которыми вы хотели бы каким-либо образом манипулировать (переименовать некоторые, удалить другие, и т. Д. ), и вы пишете скрипт, который сделает это для вас. Однако вы не совсем уверены в том, что скрипт будет работать так, как задумано, и боитесь, что он может удалить некоторые неправильные файлы. Вы также не хотите копировать всех файлов, так как это заняло бы слишком много места и времени. Одно из решений - просто создать жесткую ссылку для каждого файла в какой-то другой точке файловой системы. Если вы удалите файл в целевом каталоге, связанный объект все еще будет доступен, поскольку с ним связана другая жесткая ссылка. Создание такого количества жестких ссылок будет занимать гораздо меньше времени и пространства, чем копирование всего файла, однако это даст вам разумную стратегию резервного копирования.
Это не относится к символическим ссылкам. Помните, что символические ссылки указывают на другие ссылки (возможно, на другую символическую ссылку), а не на реальные файлы. Следовательно, я мог бы создать символическую ссылку на файл, но это только сохранит ссылку. Если (возможная) жесткая ссылка, на которую указывает символическая ссылка, удаляется из системы, попытка разрешить символическую ссылку не приведет вас к файлу. Такие символические ссылки называются «сломанными» или «висячими». Таким образом, вы не можете полагаться на символические ссылки для сохранения доступа к определенному файлу. (И наоборот, удаление символической ссылки не влияет на количество ссылок, связанных с целевым файлом.) Так что же они используют?
Зачем использовать символические ссылки?
Вы можете работать с символическими ссылками, как если бы они былифактические файлы, на которые они указывают где-то внизу строки (кроме удаления их). Это позволяет вам иметь несколько «точек доступа» к файлу, не имея лишних копий (которые остаются актуальными, поскольку они всегда имеют доступ к одному и тому же файлу). Если вы хотите заменить файл, к которому осуществляется доступ, вам нужно изменить его только один раз, и все символические ссылки будут указывать на него (до тех пор, пока сохраненный ими путь не изменится). Однако, если у вас есть жесткие ссылки на определенный файл, и вы затем заменяете этот файл другим, вам также необходимо заменить жесткие ссылки, так как в противном случае они все равно будут указывать на старый файл.
Наконец,Нередко на одной и той же Linux-машине монтируются разные файловые системы . То есть способ организации и интерпретации данных в какой-то момент в файловой иерархии (скажем, /home/gst/fs1) может отличаться от того, как они организованы и интерпретироваться в другой точке (например, /home/gst/Desktop/fs2). Жесткая ссылка может находиться только в той же файловой системе , что и файл, на который она указывает. Принимая во внимание, что символическая ссылка может быть создана в одной файловой системе, но фактически указывает на файл в другой файловой системе (см. Ответы на этот вопрос ).