Почему бы не разработать наличие softlink (символьная ссылка) и hardlink в той же “ссылке”?

Я действительно не понимаю то, что Вы имеете в виду. Я думаю, что Вы неправильно поняли, каковы жесткие ссылки. В первую очередь, весь файлы являются hardlinks. Каждый. Файл является просто ссылкой, указывающей на inode. Символьная ссылка, с другой стороны, является ссылкой, указывающей на 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

, Как Вы видите выше, удаляя файл, на который указывает hardlink, не влияет на hardlink, так как hardlink указывает на inode. softlink, с другой стороны, изменяется, когда цель удалена и воссоздана, так как новый файл теперь указывает на различный inode.

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

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

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

я думаю, что это прибывает в соответствии с заголовком: интересный эксперимент †“боролся †“не в конечном счете вознаграждение.

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

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

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

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

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

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

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

Я думаю, что Вы смущены словом “ссылка” в “hardlink” / “softlink”. Несмотря на очевидную симметрию именования, это - совершенно другие вещи.

• Гибкие ссылки:

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

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

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

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

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

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

  Можно видеть количество filename/hardlink путем выполнения ls -l. Второй столбец в выводе.

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