21

I often get anxious about the potential for incomplete data when I consider canceling a file move, regardless of whether I'm using Windows or a Unix-based system. It's sometimes tricky for me to recall how the move command functions in these environments, especially with directories. For example: Does it replicate the entire directory before removing the original, or does it handle each file one at a time, copying then deleting them sequentially?

I always realize, 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 halfway 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.

2
  • 17
    Whatever you do, just don't delete first.
    – mtone
    Jan 12, 2010 at 20:29
  • 1
    @monotone Hilarious +1 Jan 12, 2010 at 20:34

7 Answers 7

10

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

4
  • Ah, I hadn't thought about compression. Jan 12, 2010 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.
    – Signal
    Jan 12, 2010 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, 2011 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.
    – Signal
    Mar 17, 2011 at 15:00
11

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

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

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.

3
  • 2
    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, 2010 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. Jan 12, 2010 at 20:30
  • 2
    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. Jun 24, 2013 at 20:56
5

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.

4

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.

2
  • Nicely summed up. Jan 12, 2010 at 20:33
  • 1
    "a copy and delete mechanism" could be interpreted as either "copy each file, then delete it" or "copy all the files, then delete all of them". Apr 18, 2019 at 14:38
2

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.

1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .