Почему Ubuntu 12.04 64bit распознает символическую ссылку как двоичный файл?
У меня есть два файла. Один файл имеет имя gcc и является файлом оболочки. Другой файл имеет имя g++ и содержит такие данные:
!<symlink>ÿþg c c
Я могу запустить файл оболочки gcc, но файл g ++ не может работать. При попытке увидеть эту ошибку:
bash: ./g++: cannot execute binary file
Кто-нибудь может объяснить, почему я вижу эту ошибку?
вывод ls -l для этого файла:
-rwxrwxrwx 1 root root 20 May 18 11:43 g++
1 ответ
Когда Вы выполняетесь ls -l в каталоге (в Вашем видео), Вы видите это g++ не символьная ссылка. Вот то, на что похожа символьная ссылка от моей системы:
lrwxrwxrwx 1 root root 10 May 28 20:20 modules.conf -> ../modules
Отметьте строку вначале: lrwxrwxrwx - все символьные ссылки имеют это.
Можно также сказать что файл g++ не символьная ссылка, потому что при открытии ее, вместо того, чтобы видеть содержание файла, она указывает на, Вы видите некоторые другие данные.
Если файл не читаем, например, он не имеет известного заголовка или магического числа file name-of-file возвратится data и программы могут решить, что это - 'двоичный файл'. Ввести man file для больше об этом.
К обходному решению эта часть Вашей проблемы просто заменяют файлы путем создания символьных ссылок для замены поврежденных файлов, например:
Создать символьную ссылку на Ваш файл gcc именованный g++ в каталоге делают это:
ln -s gcc g++
И затем ls -l проверять. Необходимо видеть что-то как:
lrwxrwxrwx 1 zanna zanna 3 May 31 08:38 g++ -> gcc
-rwxrwxr-x 1 zanna zanna 0 May 31 08:38 gcc
Но ли Ваш envsetup сценарий будет затем работать... другой вопрос.
Как это происходило?
Вне объема вопроса действительно, но для дальнейшего расследования:
Вы упоминаете что Ваша попытка создать броски среды stray \376 and \377. Это - восьмеричная нотация для \255 и \254 который является Порядком байтов Mark, показывающий, что файл использует кодировку UTF-16. UTF-16 кодирование (с прямым порядком байтов) также представлен символами ÿþ который Вы видите в своей не-символьной-ссылке. Об этих битах кода сообщат как 'случайных', если они произойдут где-нибудь кроме в начале файла. Windows (NTFS) и другие файловые системы использует кодирование LE UTF-16 для имен файлов (и строки Unicode, которые хранят их версию символьных ссылок), таким образом, это могло происходить, потому что части путей находятся в такой файловой системе. Снова, зафиксируйте путем создания новых символьных ссылок.
Вы не можете превратить регулярный файл в символьную ссылку, потому что в общем мысе символьной ссылки метаданные, сохраненные в файловой системе, в inode таблицах.
Однако с тех пор существуют реализации символьной ссылки, которые хранят данные пути в файле, и этот метод мог использоваться в качестве нейтрализации, если существует недостаточно inodes доступно для хранения путей символьной ссылки, это, возможно, произошло, потому что у Вас нет достаточного количества inodes в разделе (взгляните с df -i .)