So if I had a cp -v operation fail, is the last file name it printed out the last successful file copy, or is it the failed partially copied file? If you had to ensure all files are copied correctly without overwriting anything, would deleting the last filename that was printed from the destination folder delete the partially copied file that the operation failed on?
Just use
rsync -va(possibly with --chown if you want user/group to be different at the destination and with --delete if you want removed files to be deleted) to continue the copy operation, it automatically takes care of figuring out which files still need to be copied and which are already there.NO STOP!
The default quick check algorithm of rsync is not safe for this. It only checks filesize and modification time to determine if files are equal. After a b0rked copy, these are not to be trusted.
You should add the
-cflag so that files are properly checksummed, unfortunately if you have slow storage on either end, this often negates the speed advantage of rsync.For example, consider this example:
mkdir source mkdir destination echo "hello" > source/file.txt echo "world" > destination/file.txt touch -r source/file.txt destination/file.txt rsync -avh source/ destination/ cat source/file.txt cat destination/file.txtContrary to what you might expect, the rsync command copies nothing and the output at the end will show:
If you change the rsync command in the example above to
rsync -c -avh source/ destination/, it will work as expected.True if the initial state is unknown but if you do your initial copy and all the later syncs with rsync it is not really necessary since rsync puts the partial files in a temporary location (there are same parameters to control the details of that too).
My memory of the cp command is that attributes such as file times were transferred at the last step. I think this would make rsync safe in most situations where a system crash wasn’t involved.
rsync -avP
Thank you!