Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
11  
Whatever you do, just don't delete first. –  mtone Jan 12 '10 at 20:29
    
@monotone Hilarious +1 –  nbolton Jan 12 '10 at 20:34

7 Answers 7

up vote 5 down vote accepted

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

share|improve this answer
    
Ah, I hadn't thought about compression. –  nbolton Jan 12 '10 at 20:34
    
You don't really need to compress, which can require a lot of time. Sometimes a compression level of 0 (storage) can do the job to move big folders across drives much faster. –  Wolf Jan 12 '10 at 20:39
    
"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." - When using Windows Explorer that's not true. It does a lot of crap, it takes ages, and you may end up with content split across two directories, see this answer to a question of mine. –  maaartinus Mar 11 '11 at 8:49
    
@maaartinus Actually, the way Windows Explorer works is it digs down recursively in the folders rather than changing the parent node. You are right though for Windows Explorer, it is not just an atomic move. I assumed command line was being used, I should have asked. –  Wolf Mar 17 '11 at 15:00

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

share|improve this answer
1  
Aha, timestamps. I had not considered that! +1 –  nbolton Jan 12 '10 at 20:26
    
Are timestamps even important honestly... –  Marcin Jan 13 '10 at 4:51
1  
@Marcin, they're there for a reason, if that's what you're asking ... –  macek Sep 16 '11 at 14:06

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.

share|improve this answer
1  
Actually, I think mv on Linux copies/deletes each file or directory individually, rather than copying the entire tree to the destination then deleting the entire tree from the source...so if you cancel halfway through, you'll end up with some files in both places, and neither directory will be complete. –  rob Jan 12 '10 at 19:38
3  
@rob: No. Directories are files like any other, and are treated the same way. The behavior you are talking about is achieved with mv verybigdir/* dest. –  dmckee Jan 12 '10 at 20:30
    
@dmckee Very useful distinction. Thanks –  tomfanning Oct 11 '11 at 20:43
    
Basically, mv handles each argument in a "cp && rm" way... mv verybigdir/* dest splits the mv of verybigdir into lots of separate move operations. Always remember that unlike on Windows, a Linux program/tool doesn't get to see that "*" there, it's expanded by the shell. –  Jürgen A. Erhard Jun 24 '13 at 20:56

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
Nicely summed up. –  nbolton Jan 12 '10 at 20:33

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.