Після отримання відповіді Стівена Кітта та обговорення цієї команди як потенційного рішення:
sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/
Я вирішив відмовитися від його запуску, поки я не оглянув те, що відбувається, ця відповідь описує те, що я з’ясував і в кінцевому підсумку робив.
Я використовую Gnu, mvякий копіює файли в ціль, тоді лише в разі успішної операції копіювання видаляється оригінал.
Однак я хотів підтвердити, чи mvвиконує ця послідовність один файл одночасно, якби це було правдою, оригінальний вміст папки був би чітко розрізаний на дві частини, одна частина зміщена до місця призначення, а інша все ще залишається в джерелі. І, можливо, був би один файл, який був перерваний під час копіювання, який був би спільним між двома каталогами - і він, ймовірно, буде неправильним.
Щоб виявити спільні файли між двома каталогами, я запустив:
~% sudo diff -r --report-identical-files my_data_on_60GB_partition/. /media/admin/mydata/. | grep identical | wc -l
14237
Цей результат припускав, що було 14 237 екземплярів одних і тих же файлів як у вихідному, так і в цільовому каталогах, я підтвердив, перевіривши файли вручну - так, було багато одних і тих же файлів в обох каталогах. Це говорить про те, що mvвидалення вихідних файлів виконує лише після копіювання великих зразків файлів. Показано швидке infoввімкнення mvкоманди
Він [ mv] спочатку використовує якийсь той самий код, який використовується cp -aдля копіювання запитуваних каталогів та файлів, потім (якщо припустити, що копія вдалася) видаляє оригінали. Якщо копія не вдається, то частина, яка була скопійована до розділу призначення, видаляється.
Я не виконував команду, але підозрюю, що намагався запустити
sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/
-i Рядок перед перезаписом , ймовірно , була б викликані більш ніж 14.000 раз.
Тоді потім з’ясуйте, скільки всього файлів у новоствореному каталозі:
~% sudo find my_data_on_60GB_partition/ -type f -a -print | wc -l
14238
Тоді, якщо в новому каталозі було загалом 14238 звичайних файлів, а 14237 мали однакові оригінали назад у джерелі, це означає, що у новому каталозі був лише один файл, який не мав відповідного ідентичного файлу у джерелі. Щоб дізнатися, що це за файл, я повернув rsync назад у напрямку джерела:
~% 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)
Швидка перевірка підтвердила, що це неправильно сформований файл, де файл існував як у вихідному, так і в цільовому, цільовому файлі = 64 МБ, оригінальний = 100 МБ. Цей файл та його ієрархія каталогів все ще належали root та ще не відновили оригінальні дозволи.
Отже, підсумовуючи:
- всі файли, які
mvніколи не дісталися, все ще повертаються у свої початкові місця (очевидно)
- всі файли, які
mvповністю копіювали, все ще мали свої оригінальні копії у вихідному каталозі
- файл, який був лише частково скопійований, все ще мав оригінал назад у вихідному каталозі
Іншими словами, всі оригінальні файли залишалися недоторканими, і рішенням у цьому випадку було просто видалити новий каталог!
Control-Z(щоб зробити паузу), а неControl-C. У цьому випадку ви зможете побачити, який файл передавались у той час, і таким чином дізнаєтесь, який файл було скопійовано лише частково. Потім ви можете спокійно вирішити, як діяти далі. (Використовуйтеkill -stopдля процесів, які не містяться в tty).