I used the terminal to copy files from one drive to another.
sudo mv -vi /location/to/drive1/ /location/to/drive2/
However that suddenly stopped, while some hours into it, and without an error, after creating a directory.
My own solution to that is often a mix of hashing and comparing which is mostly a time consuming mess as I now have to recover from an intermediate copy without really knowing which files are missing (written as very long one-liner for zsh — note that this script doesn't work in bash as written):
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; ) )
This is error prone if the name target directory or source_directory are part of the path, and delete files if they have not been moved because they were marked as duplicates. Also it does not source directory in the end.
Is there a best practice how to recover from interrupted mv?
cmp
instead of hashing. It has dependencies, and the same issues withwhile read
that Gilles mentioned. It is also slow and verbose. But it frees up disk-space sooner than the rsync method, because files are (re)moved from the source as it runs. It may serve as inspiration for the brave. – joeytwiddle Dec 01 '18 at 14:46--delete-during receiver deletes during the transfer
and also several other useful alternatives:--delete --delete-before --delete-delay --delete-after --delete-excluded
. So, yes, rsync is the best alternative, – Dec 01 '18 at 19:31mv
command work? Perhaps with*
appended to source path if the original source was a directory. – jpa Dec 02 '18 at 11:04rsync --delete*
would be a disaster! It will remove things fromdest
which are not currently insrc
, so all files which were successfully moved in the previous attempt will now be deleted! You were probably thinking ofrsync --remove-source-files
which I agree would be a good alternative. (more1, more2) – joeytwiddle Dec 03 '18 at 03:29rsync --delete
will only remove other files that are not part of the source. From man rsyncdelete extraneous files from dest dirs. Understand what extraneous means: Not being synced. And yes, rsync also provides a way to remove source files after they have been correctly transmitted. – Dec 03 '18 at 04:53mv
will restart the whole copy from zero. It will re-copy files that were already copied successfully, rsync tests for equality and leave alone files that do not need to be re-synced. – Dec 03 '18 at 04:55mv
that was interrupted. However it appears that is only the case for individual arguments passed to mv. Since the OP only specified one directory as source, then that directory should be fully intact even though mv was interrupted. In which case your--delete*
is harmless. Apologies. As others have mentioned, a--dry-run
is the safe way to be sure. – joeytwiddle Dec 03 '18 at 05:37