cp: não pode erro de status - quando o nome do arquivo tem caracteres asiáticos

Question

Estou simplesmente tentando copiar arquivos usando cp -r /home/user/source/ /home/user/destination/ , mas ele gera o erro cp: cannot stat /source/filename.xxx para alguns dos arquivos. Quando pesquisei esse erro, encontrei algumas perguntas correspondentes, como isso e isto que embora tenha o mesmo erro lançado pelo comando cp , mas as razões são diferentes. Suas soluções não resolvem meu problema.

Ao olhar de perto, vi que esse erro estava sendo gerado apenas para arquivos cujos nomes continham caracteres asiáticos. Por exemplo,

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

Alguém tem uma solução para isso? Pode ser a codificação de caracteres padrão para minha máquina não está lendo esses nomes de arquivo.

EDIT 1: A saída do meu 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: Saída de ls -l no diretório de origem

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 arquivos e informações de montagem Informações do sistema de arquivos no diretório de origem (saída de stat -f -c %T . )

ext2/ext3

Informações do sistema de arquivos no diretório de destino (saída de stat -f -c %T . )

UNKNOWN (0x482b)

Saída selecionada de 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

Esse tipo de saída de ls -l indica que foi capaz de ler um nome de arquivo no diretório, mas não conseguiu acessar o inode . O inode contém todas as informações sobre um arquivo (tipo, permissões, timestamps, etc., bem como a localização do conteúdo), exceto o nome e o conteúdo propriamente dito.

O erro "não é possível" de cp e o erro "não pode acessar" de ls estão relatando a mesma coisa: o stat system call (que retorna os metadados com nome de arquivo) falhou.

Isso pode acontecer quando você tem a permissão para enumerar os arquivos em um diretório, mas não lê seus metadados, o que é o caso se você tiver a permissão de leitura em um diretório, mas não a permissão de execução. No entanto, se esse fosse o caso, aconteceria com todos os arquivos no diretório, e ls reclamaria “permissão negada”, não “não pode acessar”. Também pode acontecer quando o o diretório está mudando tão rapidamente que os arquivos desaparecem entre o momento em que ls descobre seu nome e a hora em que lê seus metadados , mas esse não é o caso para você, presumo.

A triste explicação restante é que o sistema de arquivos está corrompido. Essas entradas de diretório podem corresponder a arquivos que se perderam ou podem ser entradas espúrias que não correspondem a nenhum arquivo.

Você pode tentar executar fsck no sistema de arquivos. Pode ou não ajudar.

Um erro no driver do sistema de arquivos é uma explicação possível, mas para o ext4 em uma instalação Linux comum usada em condições sem estresse, isso é extremamente improvável.

Uma falha no disco é mais provável. Execute smartctl -a /dev/sda para ver se o automonitoramento dos discos detectou problemas.

Também é possível que o sistema de arquivos esteja bom, mas sua máquina não está lendo corretamente devido a RAM danificada, ou que o sistema de arquivos foi corrompido devido a RAM danificada quando foi escrito. Apenas no caso, execute um teste de memória: no menu de inicialização do Ubuntu, selecione a opção de teste de memória e deixe-a executar pelo menos uma passagem completa.