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


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 .)


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)
  • As a workaround, perhaps try rsync -a source destination (rsync also has some extra advantages, like smarter resuming and integrity checks via -c). – Adam Katz Apr 3 '15 at 20:34
  • 1
    cp should be able to copy file names even if they aren't valid names in the current locale: it only needs to copy the bytes, it doesn't care what they mean. This could be a bug in cp, or in the filesystem, or the filesystem could be damaged. What is the exact error message from cp — you mention /home/user/source/ and then /source? Is this the Ubuntu machine's disk or is another filesystem involved (a Windows partition, a network mount, …)? – Gilles 'SO- stop being evil' Apr 3 '15 at 22:54
  • @richard adder requested information in question Edits. – Abhinav Apr 4 '15 at 0:07
  • @Gilles hi, cleared the /home/user/source and /source confusion in the edited question. Also, the source is a Ubuntu machine disc with ext4 filesystem and the destination is a flash drive with hfs+ filesystem. – Abhinav Apr 4 '15 at 0:11
  • can you amend edit 2 to be output of ls -la – ctrl-alt-delor Apr 4 '15 at 9:56
-????????? ? ?    ?      ?            ? 웹.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.

  • Can the following be a possible reason? I am trying to put a fresh install of OSX on an iMac (thats my only option). I got a installation usb made on a mac system earlier. It didnt work. I decided, that I copy the content from the USB (hfs+ system) on my system (ext4) and then erase the USB and make a bootable USB for the iMac on my linux machine. So bottomline, can this be happening because I made a copy first from hfs+ -> ext4 and then erased the USB and while making the bootable USB, again trying to copy the content from ext4 -> hfs+ ? – Abhinav Apr 4 '15 at 0:36
  • @Abhinav Did you make the copy on Linux or on OSX? – Gilles 'SO- stop being evil' Apr 4 '15 at 0:55
  • I made the copy from initial (failed boot) USB to my Linux machine on Linux. After making the copy, I even ran a md5sum check on the copied content on my hard drive and it was ok. I assumed then that it was fine that way. – Abhinav Apr 4 '15 at 0:57
  • @Abhinav The copy was probably ok (unless you had bad RAM already at that point) and apparently became corrupted afterwards. – Gilles 'SO- stop being evil' Apr 4 '15 at 1:02
  • "This can happen when you have the permission to enumerate the files in a directory but not read their metadata".  In a manner of speaking, that's what happens when you have read permission on the directory, but not execute permission.  But that's not what's happening here; if it were, it would affect all the files. – Scott Apr 4 '15 at 4:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.