Лучшая практика для продолжения М.В.


13

Я использовал терминал для копирования файлов с одного диска на другой.

sudo mv -vi /location/to/drive1/ /location/to/drive2/

Однако это внезапно прекратилось, через несколько часов, и без ошибок, после создания каталога.

Мое собственное решение этой проблемы часто представляет собой смесь хеширования и сравнения, которая в большинстве случаев занимает много времени, поскольку мне приходится восстанавливать промежуточную копию, не зная, какие именно файлы отсутствуют (записано как очень длинный однострочный для zsh - обратите внимание, что этот скрипт не работает в bash как написано):

source_directory="/path/to/source_directory/";
target_directory="/path/to/target_directory/";
while read hash_and_file; do {
    echo "${hash_and_file}" | read hash file;
    echo "${file}" | sed "s/^/${source_directory}/g" | read copy_from;
    echo "${copy_from}" | sed "s/${source_directory}/${target_directory}/g" | read copy_to;
    mv -v "${copy_from}" "${copy_to}" | tee -a log;
    rm -v "${copy_from}" | tee -a log; };
done <<<$(
    comm -23 <( find ${source_directory} -type f -exec sha256sum "{}" \; |
                sed "s: ${source_directory}: :g" | sort;
           ) <( find ${target_directory} -type f -exec sha256sum "{}" \; |
                sed "s: ${target_directory}: :g" | sort; ) )

Это подвержено ошибкам, если имя целевого каталога или source_directory являются частью пути, и удаляйте файлы, если они не были перемещены, поскольку они были помечены как дубликаты. Также это не исходный каталог в конце.

Есть ли лучшая практика, как оправиться от прерванного мв?


Я написал аналогичный скрипт , который использует cmpвместо хеширования. У него есть зависимости и те же проблемы, while readо которых упоминал Жиль. Это также медленно и многословно. Но он освобождает дисковое пространство раньше, чем метод rsync, потому что файлы (ре) перемещаются из источника во время его работы. Это может послужить вдохновением для смелых.
joeytwiddle

3
@joeytwiddle RSync предложения , --delete-during receiver deletes during the transferа также ряд других полезных альтернатив: --delete --delete-before --delete-delay --delete-after --delete-excluded. Итак, да, rsync - лучшая альтернатива,
Исаак

Я должен что-то упустить. Почему просто повторение одной и той же mvкоманды не работает? Возможно с *добавленным к исходному пути, если исходный источник был каталогом.
JPA

@isaac Нет, боюсь, rsync --delete*это будет катастрофа ! Он удалит вещи, из destкоторых в данный момент нет src, поэтому все файлы, которые были успешно перемещены в предыдущей попытке, теперь будут удалены! Вы, наверное, думали о том, rsync --remove-source-filesчто я согласен, будет хорошей альтернативой. ( more1 , more2 )
joeytwiddle

@joeytwiddle Нет, rsync --deleteбудет только удалить другие файлы , которые не являются частью источника. Из [man rsync] () * удалить посторонние файлы из директории dest *. Понять, что значит постороннее : не синхронизироваться. И да, rsync также предоставляет способ удаления исходных файлов после их правильной передачи.
Исаак

Ответы:


46

Забудьте о попытке заново изобрести rsync и используйте rsync.

sudo rsync -av /location/to/drive1/ /location/to/drive2/

Убедитесь, что вы используете косую черту в источнике, иначе он скопирует в /location/to/drive2/drive1.

Дважды проверьте, что команда выполнена успешно, затем запустите rm -rf /location/to/drive1/.

Команда выше перезапишет любой существующий ранее файл из drive2. Если вы хотите предложить пользователю пропустить уже существующие файлы drive2, как, например, с mv -i, это более сложно, потому что теперь вам нужно различать файлы, которые уже были скопированы и файлы, которые не были. Вы можете передать --ignore-existingопцию rsync, чтобы пропустить файлы, которые уже существуют в месте назначения, независимо от их содержимого. Обратите внимание, что если оригинал mvбыл прерван во время создания файла, этот файл останется в его полускопированном состоянии (тогда как голый rsync -aзакончит копирование).

Если вы хотите воспроизвести точное поведение mv -i, включая подсказку, это можно сделать, но это намного сложнее.

Обратите внимание, что ваш гигантский лайнер очень хрупкий. Если есть имена файлов, содержащие обратную косую черту или символы новой строки, они могут быть неправильно скопированы или даже могут заставить ваш скрипт удалить произвольные файлы. Поэтому не используйте код в вопросе, если только вы не уверены, что можете доверять именам файлов, которые не содержат обратной косой черты или новых строк.

Для дальнейшего использования я рекомендую никогда не использовать mvбольшие перемещения между приводами именно потому, что трудно контролировать, что произойдет, если оно прервется. Используйте rsync для копирования, а затем удалите оригинал.


Какие обещания дает rsync, чего нет у mv?
Что

4
ну, например, rsyncделает то, что вы пытаетесь сделать, а пока mvнет. Также: копирование между разными машинами; сжатие для передачи; пропуск файлов, существующих в месте назначения, на основе равенства на основе временной метки или хеша; настраиваемая обработка владения, разрешений, ссылок и специальных файлов; и т.д. linux.die.net/man/1/rsync
Глупый урод

1
@SillyFreak Я должен из этого сделать вывод, что я всегда должен использовать rsync вместо mv, не только, как сказал Жиль для кросс-драйва, но и для любой операции, поскольку граница «слишком большая» является относительно субъективной, и если возникает проблема все равно это было бы решено rsync?
Что

9
хорошо, когда я перемещаю файлы или каталоги внутри одного раздела, я обычно использую mv(или файловый менеджер), потому что он перемещает только ссылку на файл / каталог. Если мне нужно выполнить фактическую передачу данных, то я использую, rsyncесли выполняется одно из следующих условий: 1) я перемещаю больше файлов, чем я могу сразу проверить на правильность передачи; 2) Я ожидаю, что мне нужно будет синхронизировать файлы; 3) Я ожидаю, что передача может быть прервана. Я хочу сказать, что для случая использования, который вы представляете в вопросе, rsyncэто просто правильный инструмент, mvили cpнет.
Глупый урод

7
Я бы посоветовал всегда запускать любую команду rsync с ключами -v и -dry-run, чтобы точно подтвердить, что она собирается делать.
Даррен
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.