我只是尝试使用复制文件，cp -r /home/user/source/ /home/user/destination/但它引发了cp: cannot stat /source/filename.xxx 某些文件的错误。当我搜索这个错误时，我发现了一些匹配的问题，例如这和这尽管命令抛出相同的错误cp，但原因不同。他们的解决方案不能解决我的问题。
仔细观察后，我发现只有名称包含亚洲字符的文件才会引发此错误。例如，
cp: cannot stat /home/user/source/고정폭.collection
有人有解决方案吗？可能是我的机器的默认字符编码无法读取这些文件名。
编辑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=
ls -l编辑2：源目录中的输出
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
编辑3：文件系统和挂载信息源目录上的文件系统信息（输出stat -f -c %T .）
ext2/ext3
目标目录的文件系统信息（输出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)
答案1
-????????? ? ? ? ? ? 웹.collection
这种输出ls -l表明它能够读取目录中的文件名，但无法访问相应的文件名索引节点。 inode 包含文件的所有信息（类型、权限、时间戳等，以及内容的位置），除了名称和内容本身。
来自的“无法统计”错误cp和来自的“无法访问”错误ls都报告相同的事情：stat系统调用（返回给定文件名的元数据）失败。
当您有权枚举目录中的文件但不读取其元数据时，可能会发生这种情况，如果您拥有目录的读取权限但没有执行权限，就会出现这种情况。但是，如果是这种情况，目录中的所有文件都会发生这种情况，并且ls会抱怨“权限被拒绝”，而不是“无法访问”。也有可能发生当目录变化如此之快以至于文件在ls发现其名称和读取其元数据之间消失时但我想你也不是这样的。
剩下的悲伤的解释是文件系统已损坏。这些目录条目可能对应于已丢失的文件，或者它们可能是不对应于任何文件的虚假条目。
您可以尝试fsck在文件系统上运行。它可能有帮助，也可能没有帮助。
文件系统驱动程序中的错误是一种可能的解释，但对于在非压力条件下使用的普通 Linux 安装上的 ext4 来说，这是极不可能的。
磁盘故障的可能性更大。跑步smartctl -a /dev/sda查看磁盘的自我监控是否检测到问题。
也有可能文件系统很好，但由于 RAM 损坏，您的机器无法正确读取它，或者文件系统由于写入时 RAM 损坏而损坏。为了以防万一，运行内存测试：在 Ubuntu 启动菜单中，选择内存测试选项，并让它运行至少一次完整的测试。