Добавление -type f вызывает ошибки при поиске, когда каталог содержит файлы со специальными символами в OS X.

Я пытаюсь создать контрольные суммы MD5 для сотен тысяч фотографий на внешних дисках, используя следующую команду в OS X 10.9.5. Я получаю кучу ошибок, хотя. Я использую find с именами файлов, завершающимися нулем, которые передаются в xargs, потому что я думаю, что он работает быстрее.

find . -type f -not -name "checksums.md5" -print0 | xargs -0 md5 -r > checksums.md5

Я сузил его до использования -type f, что вы можете увидеть в следующем примере:

mymac:Finals user$ find . -name "0153*"
./0153_IMG_4812_Coniston village.jpg

mymac:Finals user$ find . -name "0153*" -type f
./0153_IMG_4812_Coniston village.jpg
find: ./0154_IMG_4814_Après hike.jpg: No such file or directory

mymac:Finals user$ find . -name "0154*"
./0154_IMG_4814_Après hike.jpg

mymac:Finals user$ find . -name "0154*" -type f
find: ./0154_IMG_4814_Après hike.jpg: No such file or directory

Когда я запускаю исходную команду на своем жестком диске, я вижу кучу этих ошибок «Нет такого файла или каталога», и эти файлы пропускаются, а контрольная сумма не вычисляется.

Любые идеи?


macos bash shell find bootcamp
person Clam    schedule 15.01.2015    source источник
comment
Действительно ли он жалуется на файл, начинающийся с 0154, когда вы используете шаблон имени 0153*? Я бы подумал, что он даже не стал бы проверять тип, так как имя не соответствовало шаблону. Некоторые другие мысли: какую файловую систему используют внешние диски? Передайте выходные данные и стандартный поток этих команд find через hexdump -C и сравните байты имени файла в обоих случаях. Также сравните с шестнадцатеричным дампом вывода ls в том же каталоге.   -  person Ken Thomases    schedule 16.01.2015
comment
Да жалуется!!!! Позвольте мне попробовать ваше предложение   -  person Clam    schedule 16.01.2015
comment
Попробуйте export LC_TYPE=C перед запуском find, может быть.   -  person Mark Setchell    schedule 16.01.2015
comment
Трудно показать отформатированный ответ, но у вас что-то с файловой системой. Файлы находятся на дисках NTFS, но ошибка не возникает, если файлы копируются локально (HFS). Hexdump показывает одинаковые значения 65 cc 80 независимо от того, находится ли файл на диске HFS или NTFS. На самом деле у меня были некоторые трудности, потому что ls 0154 * на диске NTFS также не работает, поэтому мне пришлось использовать find без -type f   -  person Clam    schedule 16.01.2015
comment
export LC_TYPE=C не помогает.   -  person Clam    schedule 16.01.2015
comment
Попробуйте просто использовать ls в каталоге, без шаблона глобуса. Очевидно, вам придется искать шестнадцатеричный дамп. Или вы можете отфильтровать его с помощью grep перед передачей в hexdump -C. т.е. ls | grep 0154 | hexdump -C.   -  person Ken Thomases    schedule 16.01.2015
comment
@Clam Может быть, вы как-то перезаписали find. Попробуйте command find ...   -  person Reinstate Monica Please    schedule 16.01.2015
comment
@KenThomases: ты был прав насчет файловой системы. Я посмотрел папку на машине с Windows. Файл нормально отображается в проводнике и открывается в средстве просмотра фотографий Windows. md5summer, однако, не мог с этим справиться. Я скопировал имя файла из Explorer в блокнот и обнаружил, что для E-grave использовался символ Unicode. Я заменил это на обычную версию ASCII (байт: 0xE8), и это решило проблему для файла под OS X. Забавно то, что hexdump -C показывает одну и ту же последовательность символов UTF-8 для сломанных и фиксированных имен файлов: 65 cc 80.   -  person Clam    schedule 16.01.2015
comment
Рассматривали ли вы возможность задать вопрос на сайте Apple Stack Exchange Ask Different?   -  person Jonathan Leffler    schedule 16.01.2015

Ответы (1)


arrow_upward
0
arrow_downward

У меня нет решения, но есть обходной путь: не копируйте файлы с диска HFS в NTFS с помощью драйверов Apple HFS (в Bootcamp), а делайте это либо через SMB, либо через общие папки VMWare Fusion (фактически SMB ?)

Есть два способа создать персонажа электронной могилы. Один из них заключается в использовании расширенного ASCII 0xE8 из CP1252, другой, как я только что узнал, по-видимому, использует байты Unicode 0x0065 (обычная буква «e», ASCII 0x65) + 0x0300 (сочетание серьезного ударения).

Когда я скопировал файл в Bootcamp, имя файла содержит последовательность байтов UTF-16le 0x65 0x00 0x00 0x03 (обычная буква «e» + сочетание серьезного ударения)

Когда я скопировал файл в VMWare Fusion либо через общую папку VMWare, либо через общую папку, имя файла содержит последовательность байтов UTF-16le 0xE800 (кодовая страница Windows 1252, расширенный символ электронной могилы ASCII).

Вернувшись в OS X, передача вывода find в hexdump -C дает одну и ту же последовательность байтов UTF-8 для обоих вариантов этого символа: 65 cc 80. Вероятно, поэтому у меня все разваливается под OS X.

person Clam    schedule 16.01.2015