Чи слід включати проміжку косої риски / у символьне посилання на каталог?


30

Посилання на каталог дає різні результати ls -lзалежно від того, я ln -s dirчи ln -s dir/. Але в чому полягає фактична різниця, і якій я повинен віддати перевагу чому?

Відповіді:


9

Немає різниці. (Була б різниця, якби ціль не була існуючою каталогом.)

Остаточний проріз може закінчитися там через завершення оболонки: з деякою конфігурацією, ln -s tarTabSpacelinkзавершує до ln -s target/ link.


Зв'язане запитання, мабуть, стосується декількох послідовних косих рисочок у шляхах, але не про те, що йде косою косою рисою на посиланнях. Я не впевнений, що тут є що сказати.
mwfearnley

Власне, я не повинен був цього говорити. Про це можна сказати зовсім про спільну проблему, яка тісно пов'язана з питанням. Я не думаю, що це все призводить до цього висновку.
mwfearnley

@mwfearnley Це логічний наслідок: якщо foo -> bar/тоді foo/quxеквівалентно bar//qux. Хоча форма запиту, формально кажучи, не включає foo -> bar/, я також обговорюю цей випадок у своїй відповіді.
Жил "ТАК - перестань бути злим"

Привіт, дякую за відгук. Він мені говорить, що шляхи, включаючи символьні посилання, рівноцінні. Це не обов'язково розказує мені, що станеться, якщо я отримаю доступ до самої посилання (без кінцевої косої риси), і не будучи експертом Unix, я не обов'язково знаю, що означає «еквівалентність» або не означає.
mwfearnley

Принаймні один крайній випадок, коли це має значення, тому мені довелося спростувати цю відповідь.
Флейм

27

Єдине, що я можу придумати, це те, що це "захищає" вас від того, щоб хтось видалив каталог і створив файл.

[user@host linktest]$ mkdir test
[user@host linktest]$ ln -s test/ slash
[user@host linktest]$ ln -s test noslash
[user@host linktest]$ ls -l
total 4
lrwxrwxrwx 1 paul paul    4 Feb 21 21:00 noslash -> test
lrwxrwxrwx 1 paul paul    5 Feb 21 21:00 slash -> test/
drwxrwxr-x 2 paul paul 4096 Feb 21 20:59 test
[user@host linktest]$ file *slash
noslash: symbolic link to `test'
slash: symbolic link to `test/'
[user@host linktest]$ rmdir test
[user@host linktest]$ file *slash
noslash: broken symbolic link to `test'
slash: broken symbolic link to `test/'
[user@host linktest]$ touch test
[user@host linktest]$ file *slash
noslash: symbolic link to `test'
slash: broken symbolic link to `test/'
[user@host linktest]$

Версія з косою рискою порушується, коли ціль замінюється файлом.


3

Питання, що цікавить Я зробив невеликий тест:

$ mkdir dir
$ ln -s dir/ test_slash
$ ln -s dir test_noslash
$ ls -l
total 4
drwxr-xr-x 2 vrusinov vrusinov 4096 Feb 21 16:41 dir
lrwxrwxrwx 1 vrusinov vrusinov    3 Feb 21 16:41 test_noslash -> dir
lrwxrwxrwx 1 vrusinov vrusinov    4 Feb 21 16:41 test_slash -> dir/
$ strace ls test_slash 2> trace_slash
$ strace ls test_noslash 2> trace_noslash
$ wc -l trace_*
   79 trace_noslash
   79 trace_slash
$ diff -u trace_* | less

Як бачите, різниці в кількості системних викликів (принаймні, для ls) немає, і сліди виглядають дуже схоже. Щоправда, це просто демпферний тест, і я не впевнений - можуть бути деякі відмінності.


Мені також цікаво, чи насправді це має значення, але навіщо тоді зберігати цю додаткову косу рису?
Тобіас Кіенцлер

2

Ваше запитання справді стосується поведінки lsпрограми.

1) Якщо ви робите, ls -l $dirде $ dir насправді є посиланням, ви отримуєте інформацію про симпосилання.

2) Якщо ви робите, ls -lL $dirде $ dir є символьним посиланням на каталог, ви отримуєте інформацію про цільовий каталог.

3) Якщо ви зробите ls -l $dir/.це, змушуйте дотримуватися символьного посилання та надає інформацію про цільовий каталог.

4) Якщо це зробити ls -l $dir/, результати можуть бути такими ж, як №1, або можуть бути такими ж, як №3, залежно від того, яка версія lsвикористовується. Я звик до старшої версії Solaris, яка робила це як номер 1, і мене здивувало, як Linux це робив як номер 3.

і якому я повинен віддавати перевагу чому?

Без останньої косої риски, якщо вас може турбувати, чи є ім'я каталогів фактичним каталогом порівняно з символьним посиланням на каталог.

З косою косою рисою, якщо вас більше турбують файли в каталозі, а не сам каталог.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.