У меня есть (ну, у меня был ) каталог:
/media/admin/my_data
Он был размером около 49 ГБ и содержал десятки тысяч файлов. Каталог является точкой монтирования активного раздела LUKS.
Я хотел переименовать каталог в:
/media/admin/my_data_on_60GB_partition
В то время я не понимал, но я выполнил команду из домашнего каталога, поэтому я сделал:
~% sudo mv /media/admin/my_data my_data_on_60GB_partition
Итак, mv
программа начала перемещаться /media/admin/my_data
и ее содержимое в новый каталог ~/my_data_on_60GB_partition
.
Я использовал Ctrl+, Cчтобы отменить команду, так что теперь у меня есть целая куча файлов, разбитых по каталогам:
~/my_data_on_60GB_partition <--- about 2GB worth files in here
а также
/media/admin/my_data <---- about 47GB of orig files in here
Новый каталог ~/my_data_on_60GB_partition
и некоторые его подкаталоги принадлежат пользователю root.
Я предполагаю, что mv
программа сначала скопировала файлы как root, а затем после передачи chown
вернула их обратно в мою учетную запись.
У меня есть несколько старых резервных копий каталога / раздела.
У меня вопрос, можно ли надежно восстановить кучу файлов, которые были перемещены?
То есть я могу просто запустить:
sudo mv ~/my_data_on_60GB_partition/* /media/admin/my_data
или я должен отказаться от попыток восстановления, поскольку файлы, возможно, повреждены и частично завершены и т. д.?
- ОС - Ubuntu 16.04
mv --version
mv (GNU coreutils) 8.25
источник
Control-Z
(паузу), а неControl-C
. В этом случае вы сможете увидеть, какой файл был передан в то время, и узнать, какой файл был скопирован только частично. Затем вы можете спокойно решить, как поступить. (Использоватьkill -stop
для процессов не в tty).(2GB + 47GB) < 60GB
. Емкость раздела составляет 60 ГБ, размер папки и ее содержимое: 49 ГБ.Ответы:
При перемещении файлов между файловыми системами
mv
не удаляет файл до завершения его копирования и обрабатывает файлы последовательно (я изначально говорил, что копирует, а затем удаляет каждый файл по очереди, но это не гарантировано - по крайней мере,mv
копии GNU затем удаляют каждую команду). аргумент строки в свою очередь, и POSIX определяет это поведение ). Таким образом, в целевом каталоге должен быть не более одного неполного файла, а оригинал все равно будет находиться в исходном каталоге.Чтобы переместить вещи назад, добавьте
-i
флаг, чтобыmv
ничего не перезаписывать:(при условии, что у вас нет скрытых файлов для восстановления
~/my_data_on_60GB_partition/
) или, что еще лучше (учитывая, что, как вы обнаружили, у вас может быть много файлов, ожидающих удаления), добавьте-n
флаг, чтобыmv
ничего не перезаписывать, но не спросить вас об этом:Вы также можете добавить
-v
флаг, чтобы увидеть, что делается.С любым POSIX-совместимым
mv
исходная структура каталогов все еще должна быть неповрежденной, так что в качестве альтернативы вы можете проверить это - и просто удалить/media/admin/my_data
... (Хотя в общем случае, я думаю, чтоmv -n
вариант является безопасным подходом - он обрабатывает все формыmv
, в том числе, напримерmv /media/admin/my_data/* my_data_on_60GB_partition/
.)Вам, вероятно, потребуется восстановить некоторые разрешения; Вы можете сделать это массово, используя
chown
иchmod
, или восстановить их из резервных копий, используяgetfacl
иsetfacl
(спасибо Сато Кацура за напоминание ).источник
find
чтобы найти и установить разрешения. В новом каталоге есть много файлов, в именах которых есть пробелы, но нет скрытых файлов - о которых я знаю. Как вы думаете, глобус в командеsudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/
расширит имя файла без проблем с разделением слов? Я думал альтернативно, я мог бы использовать,sudo rsync ~/my_data_on_60GB_partition/ /media/admin/my_data/
который я считаю, будет обрабатывать пути к файлам с пробелами?rsync
вместо этого, чтобы он также проверял целостность всех файлов. Но приятно знать, что мне это не нужно.su command mv -i ...
(илиsu /bin/mv -i ...
) вместоsudo mv -i ...
) на случай, если какой-нибудь (странный) админ сделает mv функцией, которая выполняет mv -f на системном уровне (т. Е. / Etc / profile или такие общесистемные файлы) .. команда что-то: запустить команду что-то, а не функцию или псевдоним с тем же именем. (например: можно (очень!) не повезти и иметь (очень, очень плохо!)function mv { /bin/mv -f -- "$@" }
в файле, который всегда получен, и тогда «rm -i что-то» ничего не спросит (и просто возразит, что «-i "файла не существует!) ... [Я видел такие вещи ... дрожь ]После получения ответа Стивена Китта и обсуждения этой команды как потенциального решения:
Я решил отложить его, пока не пойму, что происходит, этот ответ описывает то, что я узнал и в итоге сделал.
Я использую Gnu,
mv
которая копирует файлы в целевой каталог, тогда, только если операция копирования прошла успешно, она удаляет оригинал.Однако я хотел проверить,
mv
выполняет ли эта последовательность по одному файлу за раз, если это правда, исходное содержимое папки было бы аккуратно разделено на две части, одна часть сместилась к месту назначения, а другая все еще осталась в источнике. И, возможно, во время копирования будет один файл, который будет прерван между двумя каталогами, и он, вероятно, будет поврежден.Чтобы обнаружить файлы, которые были общими для двух каталогов, я запустил:
Этот результат показал, что в исходных и целевых каталогах было 14 237 экземпляров одинаковых файлов, я подтвердил, проверив файлы вручную - да, в обоих каталогах было много одинаковых файлов. Это говорит о том, что только после
mv
копирования больших наборов файлов выполняется удаление исходных файлов. Быстрый поиск вinfo
поmv
команде показалЯ не запускал команду, но подозреваю, что попытался запустить
-i
Подсказка перед перезаписью вероятно бы вызвало более чем 14.000 раз.Итак, чтобы узнать, сколько всего файлов во вновь созданном каталоге:
Итак, если в новом каталоге было в общей сложности 14238 обычных файлов и 14237 имели идентичные оригиналы обратно в источнике, это означает, что в новом каталоге был только один файл, который не имел соответствующего идентичного файла в исходном каталоге. Чтобы узнать, что это был за файл, я запустил rsync в направлении источника:
Быстрая проверка подтвердила, что это был неправильно сформированный файл, где файл существовал как в источнике, так и в месте назначения, файл назначения = 64 МБ, оригинал = 100 МБ. Этот файл и его иерархия каталогов все еще принадлежали пользователю root, и исходные разрешения для него еще не восстановлены.
Итак, в заключение:
mv
никогда не были найдены, все еще вернулись на свои места (очевидно)mv
копировались полностью, все еще имели свои оригинальные копии в исходном каталогеДругими словами, все исходные файлы все еще не были повреждены, и в этом случае решением было просто удалить новый каталог!
источник
-n
было бы лучше в общем случае. Я проверилmv
исходный код, он удаляет исходный аргумент за раз.mv
происходит удаление на источнике. Таким образом, командаmv foo bar baz
будет двигатьсяfoo
вbaz/foo
том удалить оригиналfoo
затем перейтиbar
кbaz/bar
..?cmp
а неdiff
сравнивать двоичные файлы. Кроме того, ваше обсуждение выше имеет смысл только при перемещении файлов между различными файловыми системами. При перемещении файлов в одной и той же файловой системе не происходит копирования.Я просто подумал, что прокомментирую, что у некоторых людей может возникнуть желание бросить «xargs» в микс для параллельной работы. Это дает мне волю, и мне действительно нравится решение rsync выше.
Что касается файловой системы о перемещении и копировании, а также о том, когда именно оригинал удаляется, VFS и базовая файловая система (системы) координируют действия, чтобы гарантировать атомарность для каждого файла перед переходом к этому этапу удаления. Таким образом, даже если он прерывается до полной записи целевого файла, вся блокировка в VFS очень строгая и защищает от таких вещей, как случайное чередование данных, даже в параллельных случаях. (Я работал над Linux VFS и NFS4)
Добавление 'xargs' к смеси, вероятно, сделало бы этап проверки двойного здравомыслия головной болью, когда несколько файлов находились в середине пути. Хотелось бы, чтобы у меня было больше сценариев на уровне системы. Хорошие напоминания для меня!
Мне понравился вопрос, он хорош для паутины и заставляет меня снова любить rsync. Ура!
источник