Eu tenho (bem, eutive) um diretório:
/media/admin/my_data
Tinha aproximadamente 49 GB de tamanho e dezenas de milhares de arquivos. O diretório é o ponto de montagem de uma partição LUKS ativa.
Eu queria renomear o diretório para:
/media/admin/my_data_on_60GB_partition
Não percebi na hora, mas emiti o comando do diretório inicial e acabei fazendo:
~% sudo mv /media/admin/my_data my_data_on_60GB_partition
Então o mvprograma começou a se mover /media/admin/my_datae seu conteúdo para um novo diretório ~/my_data_on_60GB_partition.
Eu usei Ctrl+ Cpara cancelar o comando no meio, então agora tenho um monte de arquivos divididos em diretórios:
~/my_data_on_60GB_partition <--- about 2GB worth files in here
e
/media/admin/my_data <---- about 47GB of orig files in here
O novo diretório ~/my_data_on_60GB_partitione alguns de seus subdiretórios pertencem ao root.
Presumo que o mvprograma deve ter copiado os arquivos como root inicialmente e, após a transferência, chowndevolvê-los para minha conta de usuário.
Eu tenho um backup um tanto antigo do diretório/partição.
Minha pergunta é,é possível restaurar de forma confiável o conjunto de arquivos que foram movidos?
Ou seja, posso apenas executar:
sudo mv ~/my_data_on_60GB_partition/* /media/admin/my_data
ou devo desistir de tentar recuperar, pois os arquivos estão possivelmente corrompidos e parcialmente completos, etc.?
- SO - Ubuntu 16.04
mv --version
mv (GNU coreutils) 8.25
Responder1
Ao mover arquivos entre sistemas de arquivos, mvnão exclui um arquivo antes de terminar de copiá-lo e processa os arquivos sequencialmente (eu inicialmente disse que copia e depois exclui cada arquivo por vez, mas isso não é garantido - pelo menos o GNU mvcopia e depois exclui cadaargumento de linha de comandopor sua vez, ePOSIX especifica este comportamento). Portanto você deve ter no máximo um arquivo incompleto no diretório de destino, e o original ainda estará no diretório de origem.
Para retroceder, adicione o -isinalizador para mvnão substituir nada:
sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/
(supondo que você não tenha nenhum arquivo oculto para restaurar ~/my_data_on_60GB_partition/), ou melhor ainda (dado que, como você descobriu, você pode ter muitos arquivos esperando para serem excluídos), adicione o -nsinalizador para mvnão sobrescrever nada, mas não pergunte sobre isso:
sudo mv -n ~/my_data_on_60GB_partition/* /media/admin/my_data/
Você também pode adicionar o -vsinalizador para ver o que está sendo feito.
Com qualquer compatível com POSIX mv, a estrutura de diretório original ainda deve estar intacta, então, alternativamente, você pode verificar isso - e simplesmente excluir /media/admin/my_data... (No caso geral, acho que a mv -nvariante é a abordagem segura - ela lida com todas as formas de mv, Incluindopor exemplo mv /media/admin/my_data/* my_data_on_60GB_partition/.)
Provavelmente você precisará restaurar algumas permissões; você pode fazer issoem massausando chowne chmod, ou restaure-os de backups usando getfacle setfacl(graças aSato Katsurapara olembrete).
Responder2
Depois de obter a resposta de Stephen Kitt e discutir este comando como uma solução potencial:
sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/
Decidi adiar a execução até entender o que estava acontecendo. Esta resposta descreve o que descobri e acabei fazendo.
Estou usando o Gnu mv, que copia arquivos para o destino; somente se a operação de cópia for bem-sucedida, ele exclui o original.
Porém, eu queria confirmar se mvesta sequência executa um arquivo por vez, se isso fosse verdade, o conteúdo da pasta original teria sido dividido em duas partes, uma parte deslocada para o destino, a outra ainda deixada para trás na origem. E possivelmente haveria um arquivo que foi interrompido durante a cópia, comum entre os dois diretórios - e provavelmente estaria malformado.
Para descobrir arquivos comuns entre os dois diretórios, executei:
~% sudo diff -r --report-identical-files my_data_on_60GB_partition/. /media/admin/mydata/. | grep identical | wc -l
14237
Este resultado sugeriu que havia 14.237 instâncias dos mesmos arquivos nos diretórios de origem e de destino, confirmei verificando os arquivos manualmente - sim, havia muitos arquivos iguais em ambos os diretórios. Isso sugere que somente após mvcopiar grandes quantidades de arquivos ele executa a exclusão dos arquivos de origem. Uma rápida pesquisa no infocomando mvmostrou
Ele [
mv] primeiro usa parte do mesmo código usado porcp -apara copiar os diretórios e arquivos solicitados e, em seguida (assumindo que a cópia foi bem-sucedida) remove os originais. Se a cópia falhar, a parte que foi copiada para a partição de destino será removida.
Não executei o comando, mas suspeito que se tentei executar
sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/
O-i avisar antes de substituirprovavelmente teria acionado mais de 14.000 vezes.
Então, para descobrir quantos arquivos no total no diretório recém-criado:
~% sudo find my_data_on_60GB_partition/ -type f -a -print | wc -l
14238
Então, se houvesse um total de 14.238 arquivos regulares no novo diretório e 14.237 tivessem originais idênticos na fonte, isso significa que havia apenas um arquivo no novo diretório que não tinha um arquivo idêntico correspondente na fonte. Para descobrir o que era esse arquivo, executei o rsync na direção da fonte:
~% sudo rsync -av --dry-run my_data_on_60GB_partition/ /media/admin/my_data
sending incremental file list
./
Education_learning_reference/
Education_learning_reference/Business_Education/
Education_learning_reference/Business_Education/Business_education_media_files/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/Jeff and David F interview/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/Jeff and David F interview/018 business plans-identifying main KPIs.flv
sent 494,548 bytes received 1,881 bytes 330,952.67 bytes/sec
total size is 1,900,548,824 speedup is 3,828.44 (DRY RUN)
Uma verificação rápida confirmou que este era o arquivo malformado, onde o arquivo existia tanto na origem quanto no destino, arquivo de destino = 64 MB, original = 100 MB. Este arquivo e sua hierarquia de diretórios ainda pertenciam ao root e ainda não tiveram as permissões originais restauradas.
Então, em resumo:
- todos os arquivos que
mvnunca foram alcançados ainda estão em seus locais originais (obviamente) - todos os arquivos que
mvforam copiados completamente ainda tinham suas cópias originais no diretório de origem - o arquivo que foi copiado apenas parcialmente ainda tinha o original de volta no diretório de origem
Em outras palavras todos os arquivos originais ainda estavam intactos e a solução neste caso foi simplesmente deletar o novo diretório!
Responder3
Eu apenas pensei em comentar que algumas pessoas podem ficar tentadas a colocar 'xargs' na mistura para executar as coisas em paralelo. Isso me dá arrepios e eu realmente gosto da solução rsync acima.
Quanto ao sistema de arquivos sobre como mover e copiar e quando exatamente o original é excluído, o VFS e o (s) sistema (s) de arquivos subjacente (s) se coordenam para garantir a atomicidade por arquivo antes de chegar à etapa de exclusão. Portanto, mesmo que seja interrompido antes que o arquivo de destino seja totalmente gravado, todo o bloqueio no VFS é realmente rigoroso e protege contra coisas como intercalação aleatória de dados, mesmo em casos paralelos. (Trabalhei em coisas Linux VFS e NFS4)
Adicionar 'xargs' à mistura provavelmente teria tornado a etapa de verificação dupla uma dor de cabeça, com vários arquivos no meio do trânsito. Eu gostaria de ter mais scripts no nível do sistema. Bons lembretes para mim!
Adorei a pergunta, boa para teias de aranha e me faz amar o rsync novamente. Saúde!