cp: не может статировать ошибку – когда имя файла имеет азиатские символы

Я просто пытаюсь скопировать файлы, используя cp -r /home/user/source/ /home/user/destination/ но он бросает мне ошибку cp: cannot stat /source/filename.xxx для некоторых файлов. Когда я искал эту ошибку, я нашел некоторые соответствующие вопросы, такие как это и это, хотя они имеют ту же ошибку, что и команда cp но причины разные. Их решения не затрагивают мою проблему.

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

cp: cannot stat /home/user/source/고정폭.collection

У кого-нибудь есть решение для этого? Может быть, кодировка по умолчанию для моей машины не читает эти имена файлов.

EDIT 1: выход моего locale

 LANG=en_US.UTF-8 LANGUAGE=en_US LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= 

EDIT 2: вывод ls -l в исходном каталоге

 ls: cannot access 고정폭.collection: No such file or directory ls: cannot access 기존.collection: No such file or directory ls: cannot access 모던.collection: No such file or directory ls: cannot access 웹.collection: No such file or directory ls: cannot access 재미.collection: No such file or directory total 4 -????????? ? ? ? ? ? 웹.collection -????????? ? ? ? ? ? 기존.collection -????????? ? ? ? ? ? 모던.collection -????????? ? ? ? ? ? 재미.collection -????????? ? ? ? ? ? 고정폭.collection -rw------- 1 root root 856 Jul 24 2007 PDF.collection 

EDIT 3: информация о файловой системе и монтировании. Информация о файловой системе в исходном каталоге (выход stat -f -c %T . )

 ext2/ext3 

Информация о файловой системе в каталоге Destination (выход stat -f -c %T . )

 UNKNOWN (0x482b) 

Выбранный выход mount

 /dev/sda5 on / type ext4 (rw,errors=remount-ro) /dev/sdg1 on /media/user/osx86 type hfsplus (rw,nosuid,nodev,uhelper=udisks2) /home/user/Desktop/debusb/Install OS X Mavericks.app/Contents/SharedSupport/InstallMacOSX.pkg/3.hfs on /mnt/osx type hfsplus (rw) /home/user/Desktop/debusb/Install OS X Mavericks.app/Contents/SharedSupport/InstallMacOSX.pkg/base/3.hfs on /mnt/base type hfsplus (rw) 

 -????????? ? ? ? ? ? 웹.collection 

Этот вид вывода из ls -l указывает, что он смог прочитать имя файла в каталоге, но он не смог получить доступ к соответствующему inode . Индекс содержит всю информацию о файле (тип, разрешения, временные метки и т. Д., А также расположение содержимого), за исключением имени и содержимого.

Ошибка «can not stat» из cp и ошибка «не может получить доступ» из ls сообщают одно и то же: системный вызов stat (который возвращает метаданные с именем файла) не удался.

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

Печальным, оставшимся объяснением является то, что файловая система повреждена. Эти записи каталога могут соответствовать потерянным файлам или могут быть ложными записями, которые не соответствуют никаким файлам.

Вы можете попробовать запустить fsck в файловой системе. Это может или не поможет.

Ошибка в драйвере файловой системы – это возможное объяснение, но для ext4 на установке Linux, используемой в условиях отсутствия напряжения, это крайне маловероятно.

Сбой диска более вероятен. Запустите smartctl -a /dev/sda чтобы узнать, обнаружены ли проблемы с самоконтролем дисков.

Также возможно, что файловая система в порядке, но ваша машина не читает ее правильно из-за поврежденной ОЗУ или что файловая система повреждена из-за поврежденной ОЗУ, когда она была написана. На всякий случай запустите тест памяти: в меню загрузки Ubuntu выберите опцию проверки памяти и дайте ей запустить хотя бы один полный проход.