На вид Непоследовательное поведение для “ln” и “ln-s”

[1177033] Попробуйте это,

1
16.04.2014, 04:49
3 ответа
[118639] Прочтите вашу man-страницу: Вопрос 1 = 1-я форма, это потому, что в linux все элементы считаются файлами, даже каталогами. В качестве примера, используйте ваш текстовый редактор, чтобы "открыть" /etc/, т.е.: nano -w /etc/ nano вежливо скажет вам, что /etc/ - это каталог, т.к. технически законно создавать никогда не заканчивающиеся сим-ссылки. В старые времена, до того, как была написана проверка границ, я мог иметь систему FHS с 2 файлами с именем /etc, один из которых был файлом, а другой - каталогом, и система знала разницу

(См. примечание haha в [119052]chromiumos developer guide[119053]):

Существует цикл файловой системы, потому что внутри ~/ ствола находится Опять цветы. Не думай об этом слишком долго. Если ты попытаешься использовать du -s ${HOME}/chromiumos/chroot/home вы, возможно, получите сообщение про поврежденная файловая система. Беспокоиться не о чем, а только о том. что ваш компьютер тоже не понимает эту петлю. (Если вы можете пойми эту петлю, попробуй что-нибудь посильнее.

Осмелюсь, нажми на что-нибудь посильнее :) Чтобы не допустить петлю ln требуется полный путь.

На вопрос 2 можно ответить, прочитав еще раз страницу man Посмотрите на последнее предложение:

rpm -qa | grep el
rpm -qa | grep centos
rpm -qa | grep rhel

ОПИСАНИЕ

В 1-ой форме создайте ссылку на наблюдаемый объект с именем LINK_NAME. На сайте 2-я форма, создайте ссылку на наблюдаемый объект в текущем каталоге. На сайте 3-я и 4-я формы, создайте ссылки на каждый ЦЕЛЕЗНИК в ДИРЕКТОРИИ. Создавайте жесткие ссылки по умолчанию, символические ссылки с --символикой. По адресу . по умолчанию, каждый пункт назначения (имя новой ссылки) еще не должен существуют. При создании жестких ссылок, каждый наблюдаемый объект должен существовать. Символический ссылки могут содержать произвольный текст; при последующем разрешении относительная ссылка будет иметь вид интерпретируется по отношению к родительскому каталогу.

Ре: Правка:[119061] "Однако, почему оболочка не может разобрать этот путь, когда вы выполняете команду, вместо того, чтобы заставлять пользователя разобраться в том, что это за путь и ввести его сам"?

Рассмотрим этот пример: Приложение А устанавливает библиотеку версии 1.0.a. Вы собираете приложения X,Y,Z, которые зависят от библиотеки A. Приложение А находит ошибку, обновляет ее и сохраняет библиотеку как 1.0.1.2.a. Так как приложения X,Y,и Z все еще используют библиотеку 1.0, если я напрямую заменю 1.0 на w/ 1.0. 1.2, я получу ошибку, но если я символически свяжу версию 1.0.1.2 с версией 1.0, то ничего не сломается,

и приложения X,Y, и Z получат новое исправление от библиотеки, примененной к ним тоже, потому что оболочка следует по ссылке с 1.0 на 1.0.1.2, но называет её 1.0. В таких случаях вы не хотите, чтобы оболочка брала на себя путь, так как это увеличивает шансы на общесистемный выход из строя. BTW на 64-битных системах /usr/lib связан с /usr/lib64, для исправления только что приведенного мною примера в большом масштабе, т.е. 32-битные приложения ожидают установки библиотек в /usr/lib, а на 64-битной системе нет чистых 32-битных библиотек, так что /usr/lib связан с /usr/lib64 как таковым:

rpm -qa | grep release

6
27.01.2020, 23:11

Вопрос 1: Почему для мягкой ссылки для обоих файлов/папок должен быть записан полный путь, в то время как для жесткой ссылки мы можем пропустить имя файла для целевого файла?

Вам не нужно указывать путь или имя файла и для мягкой ссылки, если только цель не находится в текущем каталоге. Например, если у вас есть файл [119026]~/Downloads/target_file[119027], вы можете это сделать:

когда вы находитесь в [119028]~/[119029], что создаст [119030] жесткую ссылку [119031] на [119032]~/Downloads/target_file[119033] в [119034]~/[119035] с именем файла [119036]target_file[119037], а также вы можете сделать

, когда вы находитесь в [119038]~/[119039], которая создаст [119040]мягкую ссылку [119041] на [119042]~/Downloads/target_file[119043] в [119044]~/[119045] с именем файла [119046]target_file[119047].

Вопрос 2: Почему путь к файлу для Старого файла/папки мягкой ссылки относительно его родителя, в то время как остальные 3 пути (Старый, Новый файлы, Новый файл/папка мягкой ссылки) относительно самих файлов/папок?

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

Вам следует прочитать [119050]ручную страницу ln[119051]. Пробовали все это на Ubuntu 14.04, но никогда меньшее не подтверждалось на странице руководства, так что вам не нужно беспокоиться об ОС; она не специфична для ОС.[118638].

2
27.01.2020, 23:11
[118795] При создании жесткой ссылки путь к источнику используется во время создания ссылки, поэтому это должен быть путь относительно текущей рабочей директории (или абсолютный путь). Когда вы создаете символическую ссылку, путь к источнику обрабатывается как строка; он будет интерпретирован при использовании ссылки, поэтому он должен быть относительно директории, в которой находится ссылка.

Рассматривая ваш пример, где текущий каталог [119202]/home/user[119203].

Команда [119502]ln -s new/file new2/file[119503] создает символическую ссылку, текстом которой является [119504]new/file[119505] и помещает эту ссылку в место расположения [119506]new2/file[119507]. Когда программа получает доступ к этой ссылке, целью является [119508]/home/user/new2/new/file[119509], которого не существует.

Команда [119510]ln -s ../new/file new2/file[119511] создает символическую ссылку, текстом которой является [119512].../new/file[119513] и помещает эту ссылку в место расположения [119514]new2/file[119515]. Когда программа получает доступ к этой ссылке, целью является [119516]/home/user/new2/.../new/file[119517], который сокращает до [119518]/home/user/new/file[119519]. Команда [119520]ln new/file new2/file[119521] создает запись директории в месте [119522]new2/file[119523], которая указывает на тот же самый файл, что и [119524]/home/user/new/file[119525] (который должен существовать).

Часто менее запутанным является переход в целевую директорию перед созданием символических ссылок.

2
27.01.2020, 23:11

Теги

Похожие вопросы