Is it better to always copy and delete, rather than move?

Question

Generally speaking, I find myself panicking when I realise that if I cancel a file move, it could cause the target or source to be incomplete. This question applies to Windows and Unix-based platforms. I can never remember exactly how the move command works in either case. For example, if you're moving a directory; does it copy the entire directory, and then delete it after, or does it copy and then delete each file individually?

I always realise, after typing something like mv verybigdir dest, that I perhaps should have typed cp -R verybigdir dest  &&  rm -R verybigdir (where the && operator proceeds to the next command only if the first was successful) -- or is this pointless? What happens, exactly, when I press Ctrl+C half way through a move? Likewise, what exactly happens on Windows when I press the cancel button?

I can't count the number of times I've moved something (the last time was when using svn) and had two directories, with split contents. I guess the answer is difficult, because not all applications move groups of files in the same way.

Answer 1

On Windows, moving to the same drive and partition will act just like Unix's mv command and rename the folder or change its parent. However, if you were to move it to another driver or partition, it would copy and delete file by file, hence why it is more efficient to use a tar file or a zip file with no compression to move files faster across partitions and hard drives. If you were to cancel it, it would simply stop where it is. I would believe the same is true for Unix but I did not experiment enough with it to be 100% sure. It is just a matter of changing the inode, but if it is on another partition or drive, then it needs to be copied to sectors on that partition or drive. If you were to cancel it during the transfer, it would already have moved some files, and the file that was being transferred will see it's destination file removed and the source file kept (transaction cancelled, but your original file still exists).

Update: If you were to cancel a move and wanted to resume it, just re-issue the order to move. It might warn you that the destination folder already exists, but the files will not be overwritten (unless they existed before the original move, or got added in between the two move orders) since as soon as they are transferred, they are deleted from the source (if on a different partition or drive).

Answer 2

Even on a perfectly stable computer that never fails: if you care about timestamps, then mv is better than plain cp.

(cp -a will preserve the timestamps for you, and I assume something similar exists on Windows).

Answer 3

No.

Explanation:

mv verybigdir dest

renames verybigdir to dest. This is an atomic operation, i.e. can not fail halfway through.

If dest is on another device, mv will copy first, then delete the old version. This is not an atomic operation. If it fails, you may have only a partial copy of verybigdir in dest, but verybigdir will still be complete.

Yes, other applications may move files differently.

Answer 4

On windows i always copy and delete instead of move. I was once moving files and this is where i first noticed a bad stick of memory. When moving the file it stopped in between and i got an error so i checked the source folder and the file was gone then i checked the destination and there was a corrupt file. This happened more frequent with bigger size files and most of them were downloads which took hours so id recommend copying and then deleting. Save yourself time in the beginning it will pay off in the end.

Answer 5

In Windows, at least, move is simply a more automated Copy&Delete. I believe mv moves each file individually, meaning ^c-ing won't lose any files, you'll just end up with your files split between two places - unlike Windows Explorer, which will un-move everything when it cancels.

My solution to this is: Never move unless I'm sure I want to move it.

Answer 6

On unix, on moves that don't cross filesystem boundaries, mv does not copy the data: it just updates the inode database in various directories. This is much faster than cp on large files.

Further, using mv across filesystem boundaries just silently invokes a copy and delete mechanism.

So I think you should prefer mv.