cp: cannot stat error - when filename has Asian characters

Question

I am simply trying to copy files using cp -r /home/user/source/ /home/user/destination/ but it throws me the cp: cannot stat /source/filename.xxx error for some of the files. When I searched for this error, I found some matching questions such as this and this which although have the same error thrown by cp command but the reasons are different. Their solutions do not address my problem.

Upon looking closely, I saw that this error was being thrown only for files whose names contained Asian characters. For example,

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

Does anyone have a solution for this? May be the default character encoding for my machine is not reading these file names.

EDIT 1: The output of my 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: Output of ls -l in the source 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
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: File System and Mount information Filesystem info on Source directory (output of stat -f -c %T .)

ext2/ext3

Filesystem info on Destination directory (output of stat -f -c %T .)

UNKNOWN (0x482b)

Selected Output of 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)

Answer 1

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

This kind of output from ls -l indicates that it was able to read a file name in the directory, but it was not able to access the corresponding inode. The inode contains all the information about a file (type, permissions, timestamps, etc., as well as the location of the contents) except for the name and the contents proper.

The “cannot stat” error from cp and the “cannot access” error from ls are both reporting the same thing: the stat system call (which returns the metadata given a file name) failed.

This can happen when you have the permission to enumerate the files in a directory but not read their metadata, which is the case if you have the read permission on a directory but not the execute permission. However, if that was the case, it would happen to all the files in the directory, and ls would complain “permission denied”, not “cannot access”. It can also happen when the directory is changing so rapidly that files disappear between the time ls discovers their name and the time it reads their metadata but that isn't the case for you either I presume.

The sad, remaining explanation is that the filesystem is corrupted. Those directory entries may correspond to files that have become lost, or they may be spurious entries that don't correspond to any files.

You can try running fsck on the filesystem. It may or may not help.

A bug in the filesystem driver is a possible explanation, but for ext4 on a run-of-the-mill Linux installation used in non-stress conditions, that's extremely unlikely.

A disk failure is more likely. Run smartctl -a /dev/sda to see if the disks's self-monitoring has detected problems.

It's also possible that the filesystem is fine but your machine isn't reading it correctly due to damaged RAM, or that the filesystem was corrupted because of damaged RAM when it was written. Just in case, run a memory test: in the Ubuntu boot menu, select the memory test option, and let it run for at least one full pass.