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

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

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?

Asked by: Guest | Views: 267

Total answers/comments: 4

Comments display order:

Guest [Entry]

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

Guest [Entry]

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

Guest [Entry]

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

Guest [Entry]

If you are using ACLs on the source filesystem, but not on the destination, mv on Linux will copy the source and then - because of the inability to set the ACLs on the destination - stop. So you end up having the file on both sides. The is no switch in mv to prevent that behaviour so in this case cp && rm is preferable.