2016-05-13 3 views
4

Python не может открыть мой simlinked-файл. Я убедился, что файл существует, и я могу получить к нему доступ. У меня создалось впечатление, что символические ссылки разрешены на уровне ОС, поэтому Python никогда не узнает об этом.Python не может открыть файл с символикой

[email protected]:~/Programming/ML/deeptank/dataset/inc (master)$ ls -lisa /Users/therold/Programming/ML/deeptank/dataset/inc/training/tanks/matilda-iv_689.png 
7870541 8 lrwxr-xr-x 1 therold staff 46 13 Mai 16:44 /Users/therold/Programming/ML/deeptank/dataset/inc/training/tanks/matilda-iv_689.png -> ../training_data/matilda-iv/matilda-iv_689.png 

Возможно, OSX решила файл с символическими ссылками. Однако open() метод Python не может мне:

[email protected]:~/Programming/ML/deeptank/dataset/inc (master)$ python 
Python 2.7.10 (default, Sep 23 2015, 04:34:21) 
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.72)] on darwin 
>>> open("/Users/therold/Programming/ML/deeptank/dataset/inc/training/tanks/matilda-iv_689.png") 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
IOError: [Errno 2] No such file or directory: '/Users/therold/Programming/ML/deeptank/dataset/inc/training/tanks/matilda-iv_689.png' 
>>> 

Любые идеи, что я делаю неправильно? Помощь очень ценится.

+4

Символьная ссылка может быть нарушена. Даже если ОС может прочитать место назначения, на которое указывает ссылка, это не означает, что пункт назначения существует. Можете ли вы проверить это? – WGH

+0

Кажется, что символическая ссылка была создана как относительная ссылка. Следовательно, глобальная установка Python не может открыть файл после разрешения относительной ссылки. – Tom

+0

Попробуйте 'ls -lL/Пользователи/therold/Программирование/ML/deeptank/dataset/inc/training/tanks/matilda-iv_689.png', чтобы подтвердить существование файла. –

ответ

5

Любые идеи, что я делаю неправильно?

Цель символической ссылки не существует.

Я не понимаю, почему я смог разрешить это в заявлении ls в моем вопросе.

Вы не были.

Команда ls по умолчанию работает по самой ссылке, а не по цели ссылки. Отсутствует опция -L, ls никогда не пытается разрешить символическую ссылку.

Рассмотрим каталог с этими двумя файлами:

$ ls -l 
-rw-rw-r-- 1 me me 6 May 13 11:58 a 
lrwxrwxrwx 1 me me 3 May 13 12:00 b -> ./a 

a представляет собой текстовый файл, содержащий шесть байт 'hello\n'. b - файл ссылки, содержащий три байта для его целевого пути: './a'. ls способен описать свойства ссылки без разыменования самой ссылки.

В отличии от этого, используйте -L вариант:

$ ls -lL 
-rw-rw-r-- 1 me me 6 May 13 11:58 a 
-rw-rw-r-- 1 me me 6 May 13 11:58 b 

ls Теперь разрешил ссылку в b, и отображает информацию о сопряженном файл. С -L, ls теперь утверждает, что b также является шестибайтовым текстовым файлом.

Наконец, рассмотрим следующее:

$ rm a 
$ ls -l 
lrwxrwxrwx 1 me me 3 May 13 12:00 b -> ./a 
$ ls -lL 
ls: cannot access b: No such file or directory 
l????????? ? ? ? ?   ? b 

Теперь b ссылка, которая решает в файл, который больше не существует. Поскольку ls -l никогда не пытается разрешить ссылку, ее выход не изменяется от предыдущего теста. (b - файл ссылки, 3 байта длиной, содержание './a'.)

Но ls -lL пытается решить проблему, не удается и отображает информацию об отказах.

+0

Еще раз спасибо за подробный ответ. – Tom