Does `cp -v` print out the file name when it starts copying it or when it's done?

FigMcLargeHuge, 6 months ago

Run an md5sum command on the last file in each location and compare. That will tell you if one of them is different and answer your question.

Frederic, 6 months ago

I think the one being currently copied? take a look at github.com/coreutils/coreutils/blob/…/cp.c :)

flux, 6 months ago

Another way to check is to

<span style="color:#323232;">strace cp testfile testfile2
</span>

and the sequence in which the message is printed and operations performed can be studied.

It’s perhaps a lot to read, but linux tracing tools are worth learning!

yuli, 6 months ago

skimming through coreutils’ copy.c, emit_verbose is called on line 2627 while copy_reg is called on line 3103 (in the implementation of copy_internal). at least on my machine, touch /tmp/foo && cp -v /tmp/{foo,bar/} returns an error after printing the verbose output.

taladar, 6 months ago

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.

tetris11, 6 months ago

rsync -avP

s38b35M5, 6 months ago

rsync even supports Alien vs Predator? What doesn’t rsync do???

luthis, 6 months ago

All hail the rsync!

We thank the rsync for it’s unwavering reliability.

Amen.

HiddenLayer5, 6 months ago

Thank you!

SpaceCadet, 6 months ago (edited 6 months ago)

Just use rsync -va

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 -c flag 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:

<span style="color:#323232;">mkdir source
</span><span style="color:#323232;">mkdir destination
</span><span style="color:#323232;">echo "hello" > source/file.txt
</span><span style="color:#323232;">echo "world" > destination/file.txt
</span><span style="color:#323232;">touch -r source/file.txt destination/file.txt
</span><span style="color:#323232;">rsync -avh source/ destination/
</span><span style="color:#323232;">cat source/file.txt
</span><span style="color:#323232;">cat destination/file.txt
</span>

Contrary to what you might expect, the rsync command copies nothing and the output at the end will show:

<span style="color:#323232;">hello
</span><span style="color:#323232;">world
</span>

If you change the rsync command in the example above to rsync -c -avh source/ destination/, it will work as expected.

taladar, 6 months ago

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).

damium, 6 months ago

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.