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/
Eu decidi adiar a execução até que fiquei sabendo o que estava acontecendo, essa resposta descreve o que eu descobri e acabei fazendo.
Estou usando o Gnu mv , que copia arquivos para o destino e, somente se a operação de cópia for bem-sucedida, excluirá o original.
No entanto, eu queria confirmar se mv executa essa sequência um arquivo de cada 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 fonte. E possivelmente haveria um arquivo que foi interrompido durante a cópia, o que seria comum entre os dois diretórios - e provavelmente seria mal formado.
Para descobrir arquivos comuns entre os dois diretórios, eu corri:
~% sudo diff -r --report-identical-files my_data_on_60GB_partition/. /media/admin/mydata/. | grep identical | wc -l
14237
Esse resultado sugeriu que havia 14.237 instâncias dos mesmos arquivos nos diretórios de origem e destino, confirmei verificando os arquivos manualmente - sim, havia muitos dos mesmos arquivos em ambos os diretórios. Isso sugere que somente após mv copiar grandes faixas de arquivos, ele executa a exclusão dos arquivos de origem. Uma pesquisa rápida no comando info on mv mostrou
It [mv] first uses some of the same code that's used by cp -a to
copy the requested directories and files, then (assuming the copy
succeeded) it removes the originals. If the copy fails, then the part
that was copied to the destination partition is removed.
Eu não executei o comando, mas suspeito se tentei executar
sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/
O aviso -i antes de sobrescrever provavelmente teria sido acionado mais de 14.000 vezes.
Então, para descobrir quantos arquivos totais no diretório recém-criado:
~% sudo find my_data_on_60GB_partition/ -type f -a -print | wc -l
14238
Então, se havia um total de 14238 arquivos regulares no novo diretório e 14237 tinha originais idênticos de volta na origem, isso significa que havia apenas um arquivo no novo diretório que não tinha um arquivo idêntico correspondente de volta a fonte. Para descobrir qual era esse arquivo, executei o rsync de volta na direção da origem:
~% 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 esse era o arquivo malformado, em que o arquivo existia na origem e no destino, arquivo de destino = 64 MB, original = 100 MB. Esse arquivo e sua hierarquia de diretórios ainda eram de propriedade do root e ainda não tinham as permissões originais restauradas.
Então, em resumo:
- todos os arquivos que
mv nunca alcançaram ainda estão de volta em seus locais originais (obviamente)
- todos os arquivos que
mv copiaram completamente ainda tiveram suas cópias originais no diretório de origem
- o arquivo que foi parcialmente copiado 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 era simplesmente excluir o novo diretório!