cp: no se puede establecer el error – cuando el nombre de file tiene caracteres asiáticos

Simplemente bash copyr files usando cp -r /home/user/source/ /home/user/destination/ pero me lanza el error cp: cannot stat /source/filename.xxx para algunos de los files. Cuando busqué este error, encontré algunas preguntas coincidentes como this y this que, aunque tienen el mismo error arrojado por el command cp pero las razones son diferentes. Sus soluciones no abordan mi problema.

Al mirar de cerca, vi que este error se estaba lanzando solo para los files cuyos nombres contenían caracteres asiáticos. Por ejemplo,

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

¿Alguien tiene una solución para esto? Puede ser la encoding de caracteres pnetworkingeterminada para que mi máquina no lea estos nombres de file.

EDIT 1: El resultado de mi 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: Salida de ls -l en el directory fuente

 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: Sistema de files e información del sistema de files de assembly en el directory de origen (salida de stat -f -c %T . )

 ext2/ext3 

Información del sistema de files en el directory de destino (salida de stat -f -c %T . )

 UNKNOWN (0x482b) 

Salida seleccionada del 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/ShanetworkingSupport/InstallMacOSX.pkg/3.hfs on /mnt/osx type hfsplus (rw) /home/user/Desktop/debusb/Install OS X Mavericks.app/Contents/ShanetworkingSupport/InstallMacOSX.pkg/base/3.hfs on /mnt/base type hfsplus (rw) 

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

Este tipo de salida de ls -l indica que fue capaz de leer un nombre de file en el directory, pero no pudo acceder al inodo correspondiente. El inode contiene toda la información sobre un file (tipo, permissions, marcas de time, etc., así como la location de los contenidos), excepto el nombre y los contenidos propios.

El error "no se puede establecer" de cp y el error "no se puede acceder" desde ls informan lo mismo: la llamada al sistema stat (que devuelve los metadatos dados un nombre de file) falló.

Esto puede suceder cuando tiene permiso para enumerar los files en un directory pero no lee sus metadatos, que es el caso si tiene el permiso de lectura en un directory pero no el permiso de ejecución. Sin embargo, si ese fuera el caso, pasaría a todos los files en el directory, y se quejaría "permiso denegado", no "no se puede acceder". También puede suceder cuando el directory está cambiando tan rápidamente que los files desaparecen entre el momento en que descubre su nombre y el momento en que lee sus metadatos, pero ese no es el caso para usted, supongo.

La triste y restante explicación es que el sistema de files está dañado. Esas inputs de directory pueden corresponder a files que se han perdido, o pueden ser inputs falsas que no se corresponden con ningún file.

Puede intentar ejecutar fsck en el sistema de files. Puede o no ayudar.

Un error en el controller del sistema de files es una posible explicación, pero para ext4 en una installation Linux ordinaria utilizada en condiciones no estresantes, eso es extremadamente improbable.

Una falla de disco es más probable. Ejecute smartctl -a /dev/sda para ver si el autocontrol de los discos ha detectado problemas.

También es posible que el sistema de files esté bien pero su máquina no lo está leyendo correctamente debido a la RAM dañada, o que el sistema de files estaba dañado debido a la memory RAM dañada cuando se escribió. Por si acaso, ejecute una testing de memory: en el menu de inicio de Ubuntu, select la opción de testing de memory y déjela ejecutar al less un pase completo.