11

Is there a difference between bulk-moving files with Drag & Drop vs mv?

Use case:

Volume External_Drive_A has about 8000 files totalling 9GB. External_Drive_B has 74GB of free space. The desired end result is to move all the files from A to B so that A can be wiped and put to use in another location.

Drag & Drop approach is to open one Finder window for A, another Finder window for B, highlight all the files on A, then command-click-drag them to B.

mv approach is to open a Terminal session and invoke 

mkdir /Volumes/External_Drive_B/A_legacy
mv /Volumes/External_Drive_A/* /Volumes/External_Drive/B/A_legacy/

Does Drag & Drop do anything behind-the-scenes in addition to the copy and remove, or is it strictly a thing of Beauty?

Answered by jmlumpkin below:

They differ! Drag & Drop brings the metadata, mv does not. I tested this by adding a phrase to the Spotlight Comments section on a text file's Get Info dialog. When I dragged and dropped the file across volumes, the phrase was present when I invoked Get Info on the destination; but when it used mv, the phrase was missing when I invoked Get Info on the destination.

Improve this question
1
  • it's a bit confusing, as the man page for mv states: "The mv utility now supports HFS+ Finder and Extended Attributes and resource forks. The mv utility will no longer strip resource forks off of HFS files. For an alternative method, refer to cp(1)." so where is this spotlight information stored then?
    – Robert S Ciaccio
    Dec 20, 2010 at 6:49

3 Answers 3

Reset to default
6

In earlier versions of the Mac OS, Dragging and Dropping a file was actually closer to the 'ditto' command to retain resource forks, etc.

Improve this answer
2
  • 1
    Thanks for introducing me to the ditto command. Its man page lists all sorts of nifty features, including thinning Universal binaries and HFS meta-data information.
    – Thomas L Holaday
    Dec 13, 2010 at 2:57
  • its a great tool. We used to use this more than 'mv' when moving stuff between machines/servers/local drives or even on the main drive.
    – jmlumpkin
    Dec 13, 2010 at 13:05
7

Do not use mv or drag&drop for moving data between volumes.

If anything bad happens during the operation, you will end up with half the data here and half the data there, and it will be hard to figure out where to restart. If this is done over the network, you may not even still have all the data on either volume.

Do a copy (command line or drag&drop), and after that succeeded, delete the source.

Improve this answer
3
  • So of course I have egg on my face, I missed the whole "batch files" thing. I suggest neither mv, nor cp, but rsync instead. Thilo, I'm very sorry. I had a one-large file use case in my head despite this thread regarding batches of files.
    – Jason Salaz
    Dec 13, 2010 at 3:18
  • For a cross-volume multi-file move executed as a copy - delete, is (cp ⊕ rsync) followed by rm equivalent to a GUI copy followed by a GUI trash followed by a GUI empty-trash?
    – Thomas L Holaday
    Dec 13, 2010 at 16:35
  • @Thomas L Holaday: Well, a GUI empty-trash could permanently delete all kinds of unrelated stuff already in the trash bin. I think there is a way to delete from the GUI bypassing the trash bin, maybe some option key combination, I can never remember those. That would be a good new question.
    – Thilo
    Dec 15, 2010 at 0:42
2

The end result is probably the same, but I would guess that edge cases might be treated differently, also depending on which mv you use (the default in /bin/ or a GNU version in /sw/bin/ from fink, or from macports, etc.)

For example, an OS X alias or resource forks might not be treated properly by the unix toolchain, and there are probably cases where low-level unix file things might not be handled by the OS X drag-and-drop.

Improve this answer
0

You must log in to answer this question.

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