Почему бы дизайну не иметь softlink (символическую ссылку) и hardlink в одной и той же "ссылке"?

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

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

$ 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

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

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

Я думаю, что вас смущает слово "ссылка" в "жесткая ссылка " / "мягкая ссылка ". Несмотря на кажущуюся симметрию именования, это совершенно разные вещи.

• Мягкие ссылки:

  Если вы пришли из какого-то Microsoft фона, может быть, было бы проще сказать, что: мягкая ссылка очень близка к тому, что ярлык. Это (почти) обычный файл, в котором есть путь.

  Единственная разница в Unix, в ОС есть какая-то магия для автоматического перенаправления приложений. А именно, когда приложение open() sa, ОС проверит S_IFLNK Флаг режима для файла - если он установлен, это означает, что он содержит только путь к другому файлу, и ОС будет прозрачно перенаправлять вызов по этому пути.

• Жесткие ссылки:

  Жесткая ссылка - это просто технический термин для "имени файла". Когда вы "создаете жесткую ссылку", вы просто добавляете второе имя для того же файла. Весь рабочий процесс выглядит примерно так:

  • Когда вы создаете файл, он автоматически получает первое имя файла.
  • Вы можете добавить дополнительные имена файлов, если хотите.
  • Вы не можете на самом деле удалить файлы в Unix. rm Команда только удаляет имя файла. Это гораздо более очевидно, когда вы знаете, что фактическая операция, которую он выполняет, называется unlink() ИНГ
  • Когда у файла больше нет имени файла, он удаляется. (*)

  Как примечание, каталоги всегда имеют как минимум два имени файла: одно в родительском, а другое в себе (.). Кроме того, если каталог имеет подкаталоги, он будет иметь дополнительную жесткую ссылку в каждом подкаталоге с именем ..,

  Вы можете увидеть количество файлов / жестких ссылок, запустив ls -l, Второй столбец в выводе.

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

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

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

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

[Довольно сложно найти главу и стих о псевдонимах HFS+ (sc, я не смог найти ни одного за 10 минут поиска, только сейчас), поэтому, если у кого-то есть конкретные ссылки, не стесняйтесь редактировать этот ответ.]

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

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

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

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

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

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