Почему бы не разработать с помощью softlink (symlink) и hardlink в том же & ldquo; link & rdquo ;?

Я не совсем понимаю, что вы имеете в виду. Я думаю, вы неправильно поняли, какие жесткие ссылки есть. Прежде всего, все файлы являются hardlinks. Каждый из. Файл - это просто ссылка, указывающая на индексный дескриптор. Символьная ссылка, с другой стороны, является ссылкой, указывающей на жесткую ссылку (на путь). Как можно объединить два?

Более того, функциональность очень отличается. Рассмотрим это:

$ echo "This is file" > file
$ ln -s file softlink
$ ln file hardlink
$ cat softlink 
This is file
$ cat hardlink 
This is file
$ rm file
$ echo "This is a different file" > file
$ cat softlink 
This is a different file
$ cat hardlink 
This is file

Как вы можете видеть выше, удаление файла, на которое указывает жесткая ссылка, не влияет на жесткую ссылку, поскольку жесткая ссылка указывает на индексный дескриптор. С другой стороны, программная ссылка изменяется, когда цель удаляется и воссоздается, так как новый файл теперь указывает на другой индексный дескриптор.

Кроме того, поскольку hardlinks указывают на inodes, а не на пути файловой системы, они не могут быть относительными. Очень часто полезно иметь симлинк, указывающий, например, на ../../foo. Таким образом, мы можем переместить всю структуру каталогов в другое место и переименовать все, что угодно, но ссылка не сломается. Итак, если мы перейдем к другому каталогу, softlink всегда будет указывать на foo, который находится на двух уровнях вверх. Однако жесткая ссылка просто укажет на то, какой индекс, который он был создан, чтобы указать, и перемещение каталога не повлияет на него. Иногда это то, чего мы хотим, а иногда и нет. Такая универсальность очень полезна.

Я думаю, вас смущает слово «ссылка» в «hardlink» / «softlink». Несмотря на кажущуюся симметрию имен, это совершенно разные вещи.

Soft links: Если вы исходите из какого-то фона Microsoft, возможно, было бы легче сказать, что: softlink довольно близок к тому, что является ярлыком. Это (почти) обычный файл, имеющий в нем имя пути. Единственная разница в Unix, ОС имеет некоторое волшебство для перенаправления приложений автоматически. А именно, когда файл приложения open() sa, ОС проверяет флаг режима S_IFLNK в файле - если он установлен, это означает, что он содержит только путь к другому файлу, и ОС будет прозрачно перенаправлять вызов на этот путь. Жесткие ссылки: жесткая ссылка - это просто технический термин для имени файла. Когда вы создаете жесткую ссылку, вы просто добавляете второе имя для того же файла. Весь рабочий процесс выглядит примерно так: при создании файла он автоматически получает первое имя файла. Если хотите, вы можете добавить дополнительные имена файлов. Вы действительно не можете удалять файлы в Unix. Команда rm удаляет только имя файла. Это гораздо более очевидно, когда вы знаете, что фактическая операция, которую он выполняет, называется unlink() ing. Когда файл больше не имеет имени файла, он удаляется. (*) В качестве побочного кода в каталогах всегда есть как минимум два имени файла: один в своем родителе и один сам по себе (.). Кроме того, если каталог имеет подкаталоги, он будет иметь дополнительную жесткую ссылку в каждом подкаталоге с именем ... Вы можете увидеть количество имени файла / hardlink, выполнив ls -l. Второй столбец на выходе.

(*): если какой-то процесс использует файл, удаление откладывается до тех пор, пока оно больше не будет использоваться. Тем временем у вас есть файл без имени, которое вы не видите или не получаете.

Идея, которую вы описываете, существует уже в форме «Alias» в файловой системе Apple HFS +. Если вы создаете псевдоним для файла, вы можете использовать этот псевдоним для ссылки на файл в будущем. Псевдоним использует смесь inode-эквивалента (HFS + не имеет inodes как таковой), имя файла и ... другие материалы для повторного поиска файла, используя алгоритм, который намеренно недокументирован.

[d2 ] Прагматически - это означает, что для большинства нетехнических пользователей это работает очень хорошо, потому что изменение имени файла изменяется, и перемещения файлов, которые люди делают на практике, обрабатываются достаточно хорошо (DWIM и все такое); и недокументированный характер алгоритма разрешения означает, что Apple имеет право настраивать эвристику, если найдет что-то, что работает лучше. Это хорошая вещь, в принципе. С другой стороны, это раздражает ад из всех, кто предпочел бы, чтобы их компьютеры были детерминированными, черт возьми!

Я думаю, что это происходит под заголовком: интересный эксперимент - сильно подтолкнул - не в конечном итоге вознаграждение.

Я думаю, что в настоящее время Apple не подталкивает «псевдоним» в своей технической документации. [Трудно найти главу и стих на псевдонимах HFS + (sc, я не смог найти ни одного из 10 минут поиска, только сейчас), поэтому, если у любого детерминированного есть конкретные ссылки, чувствуйте бесплатно отредактировать этот ответ.]

Прежде чем я начал использовать Unix, я использовал AmigaOS, у которого есть ссылки, у которых есть некоторые аспекты символических ссылок и hardlinks. Я никогда не понимал, как они себя ведут.

Тогда мне пришлось использовать Unix-системы (и позже Linux). Я обнаружил, что обе символические ссылки и жесткие ссылки легко понять сами по себе. До сих пор я до сих пор не понимаю гибридную конструкцию, используемую для ссылок в AmigaOS.

Из принципа наименьшего удивления я считаю, что различие между символическими ссылками и hardlinks является очень хорошей конструкцией. Ни у кого из них нет сюрпризов.

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

Я не могу представить, как вы объединили бы эти два в единую концепцию, не сделав ее чрезвычайно сложной. И это было бы основным аргументом против изменения дизайна. Лучше иметь отдельные функции, каждый из которых прост для понимания, чем одна сложная функция.

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