То куда указывает линк — не существует. Что не понятно?

Не дочитал :-)

Проблема не воспроизводится

Версия: системы, утилит, файловой системы?

Неее, тогда бы написало что это broken symbolic link to <xxx>
Про версию системы ничего не скажу, только то, что ядро там ещё .18, а file 4.17.

К системе есть только пользователь; у пользователя sbin не доступен даже на листинг (-x нету), lsb_release.d пустое.

uname? Тоже не воиспродится.

user@host [~/kitchen]# file ../kitchen

Есть версия, что шелл настроен показывать более короткие имена, если есть линка, а реальная директория уже kitchen.2011-06-04 . Реквестирую то же, но с pwd.

Интересно, а как у тебя первое `cd ../` сработало? Чудеса какие-то!

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

Т.е. по `cd ../` из твоей кухни ты должен был попасть в родительскую директорию для kitchen.2011-06-04, но никак не в хомяк!

Или у тебя kitchen.2011-06-04 тоже в хомяке лежит? Если да, то непонятна последняя ошибка.

вот:

cd /tmp
file adir
adir: symbolic link to `/tmp/0/dir/'
cd adir
pwd
/tmp/adir
ls ..
dir/
cd ..
pwd
/tmp

Т.е. получается такая ситуация: для cd путь берется из кэша директорий (наверное, того же, которым можно управлять еще и при помощи pushd, popd), а вот ls кэшем не пользуется.

kitchen: symbolic link to `kitchen.2011-06-04'

судя по всему они в одной директории лежат

file ../kitchen

вот здесь покажи stat вместо file. И раньше тоже.

И да, это не какая-нить fat/ntfs/etc?

Тогда непонятно, почему

../kitchen: ERROR: cannot open `../kitchen' (No such file or directory)

вангую также то, что буква c может быть русской, и могут быть невидимые символы.

кроме того, может быть запрет чтения ../

В этом случае доступ будет (если знать имя), но получить список файлов нельзя (а команде file такой доступ нужен, что-бы найти и проверить, куда симлинк направлен).

Linux 2.6.18-028stab101.1 #1 SMP Sun Jun 24 19:50:48 MSD 2012 x86_64 x86_64 x86_64 GNU/Linux
Древность.

$ls|grep kitchen
completekitchen/
kitchen@
kitchen_10.12.2012.tar
kitchen.2011-03-15/
kitchen.2011-06-04@
$file kitchen.2011-06-04
kitchen.2011-06-04: symbolic link to `tars/kitchen.2013-01-09'
$cd kitchen/
$pwd
/home/<user>/kitchen
$stat ../kitchen
stat: cannot stat `../kitchen': No such file or directory
$ls ../
./  ../  kitchen.2013-01-09/  kitchen.2013-01-09.tar

Т.е., pwd чому-то отображает одно, а на деле другое, и возврат в директорию по-другому происходит, раз из симлинка возвращаемся. Забавно и непонятно.

P.s. мусорка однако жуткая.

две диры: А и Б. В А лежит симлинк С на Б/В. т.е.

/А
/А/С -> /Б/В
/Б
/Б/В

Когда ты делаешь cd А/С, то перемещаешься в /Б/В на самом деле, т.е. из этой диры родитель будет /Б, где нет никакого /С. Не выйдет cd ../С из этой диры.

Я прав?

Не совсем прав.

freebsd/openbsd:

%cd test
%ls
%mkdir A
%mkdir A/C
%mkdir B
%mkdir B/
%ln -s
%cd B
%ln -s ../A/C D
%file D
D: symbolic link to `../A/C'
%cd ../
%ls
A       B
%cd B/D
%pwd
/usr/home/neko/test/A/C
%cd ../
%ls
C

user@host [~]# mkdir test
user@host [~]# cd test
user@host [~/test]# mkdir -p A/B
user@host [~/test]# mkdir C
user@host [~/test]# cd C
user@host [~/test/C]# ln -s ../A/B D
user@host [~/test/C]# cd ../
user@host [~/test]# cd C/D
user@host [~/test/C/D]# pwd
/home/user/test/C/D
user@host [~/test/C/D]# cd ../
user@host [~/test/C]# ls
./  ../  D@
user@host [~/test/C]#

Не выйдет cd ../С из этой диры.

cd в случае линукса выйдет. а вот file не узнает (как и tar, например).

/dev/vzfs reiserfs

И, кстати, забавно, что нода для reiserfs названа так.

reiserfs

а fsck ничего не показывает?

ИМХО это циклическая ссылка ибо kitchen → kitchen.2011-06-04 => kitchen/../kitchen.2011-06-04. Т.е. симлинк рекурсивно ссылается на хардлинк. Ибо на самом деле .. лежит совсем не в pwd, т.к. pwd всего лишь симлинк, и физически не существует такого каталога. У меня в EXT4 такое нормально разименуется, хотя сложно придумать что-то кривее такого пути. Как оно должно работать в reiser — не знаю. Может и никак.

$stat ../kitchen

zsh (если судить по @)? Ежели так, я бы этому сложному комбайну не сильно доверял, мало ли как он резолвит .. , там много всяких опций. А что говорят более консерватиные оболочки?

ну то бишь, находясь в kitchen/ ты на самом деле находишься в kitchen.2011-06-04, что доказывает совпадение inode файла ./, хотя кажется, что это kitchen/. На самом деле inode этого файла совсем другой. Но вот на EXT4 это не приводит к разночтению. А на твоей ФС — приводит. Сл-но либо ФС кривая(битая), либо она как-то иначе работает, и я не знаю как.

это циклическая ссылка ибо

Нет.

и физически не существует такого каталога.

Нет, там лежат 300 мегабайт джанго-проекта.

Нет. bash. (хотя он не сильно более консервативный.)

file: no such file or directory (комментарий)

Нет. bash. (хотя он не сильно более консервативный.)

Забавно, похоже по умолчанию некоторая нецелостность / «неконсистеность»: внутренние команды трактуют .. относительно символьной ссылки, а внешние - относительно cwd.

Но вроде это проблема подхода оболочек, а не `coreutils'.

Вот что написано в man 7 path_resolution:

       If the component is found and is a symbolic link  (symlink),  we  first
       resolve this symbolic link (with the current lookup directory as start‐
       ing lookup directory).  Upon error, that error  is  returned.   If  the
       result  is not a directory, an ENOTDIR error is returned.  If the reso‐
       lution of the symlink is successful and returns a directory, we set the
       current  lookup  directory to that directory, and go to the next compo‐
       nent.

$ file /tmp/xxx1
/tmp/xxx1: symbolic link to `xxx.dir'
$ ls /tmp/xxx1/../xxx1
ls: невозможно получить доступ к /tmp/xxx1/../xxx1: Нет такого файла или каталога

Собственно не замечал, поскольку в zsh у меня давно chase_dots (man zshoptions).

и физически не существует такого каталога.

Нет, там лежат 300 мегабайт джанго-проекта.

да не лежит там ничего. Твои 300Мб лежат в kitchen.2011-06-04, а в симлинке ничего лежать не может, кроме пути в kitchen.2011-06-04. В т.ч. и хардлинк .. тоже лежит в kitchen.2011-06-04. Просто твоя оболочка показывает другое имя файла (моя тоже). Такая вот неожиданная багофича pwd.

..
Я про то, что линк не циклический и директория реально существует.

*как только что выяснил).

BTW у bash есть -P

внутренние команды трактуют .. относительно символьной ссылки

они вот как-то запоминают, какой сейчас PWD. Ну а .. просто хардлинк, и он никак не может лежать в симлинке. ls -i пишет inode точки такой, как у каталога, но вот PWD указывает на симлинк.

Дык, в том-то и дело, что внешние команды работают с ФС, а внутренние — с кэшем директорий.

Вся загвоздка в баше!

Я про то, что линк не циклический и директория реально существует.

существует, но не в том месте, где ты её ищешь. Ты её ищешь там, где она должна быть, но её там нет. Вот тебе ENOENT и выводит (но это странно, потому-что у меня есть _другой_ .. в другом месте, который тем не менее, выводит куда надо. Я всё-же рекомендую fsck прогнать).

Ну а .. просто хардлинк, и он никак не может лежать в симлинке.

Внутренним командам не надо знать что лежит в симлинке. Проще прочитать man в районе опции -P и cd (у него локальная -P), таки формальнее.

Дык, в том-то и дело, что внешние команды работают с ФС, а внутренние — с кэшем директорий. Вся загвоздка в баше!

внутренние только _показывают_ свой кеш, а работают они с одним и тем же. Ты можешь вообще $PWD удалить, и сам проверить.

Не в баше, а в path_resolution. См. file: no such file or directory (комментарий), там в конце пример команды, которая работает не так, как ожидается.

А, не так понял сообщение.. Да, баш что-то подшаманивает с командами вроде cd.

Внутренним командам не надо знать что лежит в симлинке. Проще прочитать man в районе опции -P и cd (у него локальная -P), таки формальнее.

короче: власти скрывают ☺

В общем, вместо башевского cd надо cd из coreutils использовать ☺

В общем, вместо башевского cd надо cd из coreutils использовать

ха-ха-ха.. Он поменяет cwd у баша?)

☺

В общем, вместо башевского cd надо cd из coreutils использовать

у тебя он есть??

☺

Он поменяет cwd у баша?

ну а что ему остаётся делать?

Since cd affects the current shell execution environment, it is always provided as a shell regular built-in.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html