По-видимому, непоследовательное поведение для «ln» & «ln -s»

Как мы все знаем, команда ln создает ссылку, причем по умолчанию используется жесткая ссылка и опция -s создает символическую ссылку. Общий синтаксис: ln [-s] OLD NEW , где OLD – это файл, к которому вы привязываетесь, и NEW – это новый файл, который вы создаете. Жесткие ссылки не могут быть созданы для каталогов, так как жесткая ссылка может быть создана между папками внутри друг друга. Я полагаю, что компьютеры еще не имеют ресурсов для проверки этого без серьезного замедления.

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

Например, скажем, что мы находимся в папке HOME, /home/user , также известной как ~ , и создаем 2 папки, new и new2 , с file в new папке. Если мы попробуем ln -s new/file new2/file , результатом будет ~/new2/file ссылка из ~/new2/file ~/new2/new/file несуществующий ~/new2/file ~/new2/new/file . Однако, если мы вместо этого запускаем ln -s ../new/file new2/file , получаем ожидаемый результат, который является ссылкой из ~/new2/file в ~/new/file .

Итак, мой вопрос:

Почему путь файла для OLD-файла / папки символической ссылки относительно родительского объекта, в то время как остальные 3 пути (файлы OLD OLD, NEW, файл / папка символической ссылки NEW) относятся к текущей папке?

Все это в Fedora, но я уверен, что это относится к большинству ОС на базе UNIX.

EDIT E Картер Янг, кажется, ударил ноготь по голове в отношении моего второго вопроса (а также мой 1-й вопрос, который в любом случае был неправильным). Кажется, что для символической ссылки цель еще не существует, поэтому система должна сделать свой путь относительно ссылки, а не текущей. Однако почему оболочка не может анализировать этот путь при запуске команды, а не заставлять пользователя понять, что путь и ввести его сам? Скорлупа, похоже, хорошо разбирается, так же как и в случае с устаревшими проблемами? Проблемы с производительностью? Какие?

  • Почему ln -s создает относительные сломанные ссылки?
  • Symial aliasing файлы в подкаталогах без изменения текущего каталога
  • ln -s удаляет часть имени файла, когда filename передается как переменная
  • Создание символических ссылок с подстановочными знаками
  • Как я могу синхронизировать все PDF-файлы из одного каталога с Dropbox?
  • В чем разница между командами link и ln?
  • Записывает ли `ln -sf` существующие файлы, которые являются только символическими ссылками
  • ln -s с дорогой относительно pwd
  • 3 Solutions collect form web for “По-видимому, непоследовательное поведение для «ln» & «ln -s»”

    Прочтите свою страницу: Вопрос 1 = 1-я форма, это потому, что в Linux все элементы считаются файлами, даже каталогами. В качестве примера используйте текстовый редактор для «открытия» / etc /, то есть: nano -w / etc / nano будет вежливо сказать вам / etc / это каталог. Поскольку технически законно создавать бесконечные символические ссылки. В прежние времена, прежде чем была отмечена проверка границ, я мог бы иметь систему FHS с двумя файлами с именем / etc, один из которых был файлом, а один – каталогом, и система знала разницу

    (См. Примечание haha ​​в руководстве разработчика Chromeium :

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

    Я вас осмеливаюсь, нажмите на что-то более сложное 🙂 Чтобы предотвратить цикл, требуется полный путь.

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

    ОПИСАНИЕ

      In the 1st form, create a link to TARGET with the name LINK_NAME. In the 2nd form, create a link to TARGET in the current directory. In the 3rd and 4th forms, create links to each TARGET in DIRECTORY. Create hard links by default, symbolic links with --symbolic. By default, each destination (name of new link) should not already exist. When creating hard links, each TARGET must exist. Symbolic links can hold arbitrary text; if later resolved, a relative link is interpreted in relation to its parent directory. 

    Re: Edit: «Однако почему оболочка не может анализировать этот путь при запуске команды, а не заставлять пользователя понять, что это за путь и войти в него?»


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

     ln -s /usr/lib64/libfoo-1.0.1.2.a /usr/lib64/libfoo-1.0.a 

    и приложения 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 следующим образом:

     ln -s /usr/lib64 /usr/lib 

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

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

     ln `~/Downloads/target_file` 

    когда вы находитесь в ~/ , что создаст жесткую ссылку на ~/Downloads/target_file в ~/ с именем файла target_file и вы также можете сделать

     ln -s `~/Downloads/target_file` 

    когда вы находитесь в ~/ , что создаст мягкую ссылку на ~/Downloads/target_file в ~/ с именем файла target_file .

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

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

    Вы должны прочитать страницу руководства ln . Попробуйте все это на Ubuntu 14.04, но тем не менее подтвердили с помощью страницы руководства, поэтому вам не нужно беспокоиться о ОС; он не зависит от ОС.

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

    Учитывая ваш пример, где текущий каталог – /home/user .

    • Команда ln -s new/file new2/file создает символическую ссылку, текст которой является new/file и помещает эту ссылку в место new2/file . Когда программа обращается к этой ссылке, целью является /home/user/new2/new/file которого нет.
    • Команда ln -s ../new/file new2/file создает символическую ссылку, текст которой является ../new/file и помещает эту ссылку в место new2/file . Когда программа обращается к этой ссылке, целью является /home/user/new2/../new/file который сокращается до /home/user/new/file .
    • Команда ln new/file new2/file создает запись в new2/file которая указывает на тот же файл, что и /home/user/new/file (который должен существовать).

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

     cd new2 ln -s ../new/file . 
    Linux и Unix - лучшая ОС в мире.