Move files instead of copying them on a Mac

Dragging a folder to an external drive and finding it still sitting in the original location is not a bug. The Finder made a decision based on where the destination is, and that decision differs depending on whether the source and destination share a volume. Once the rule is visible, the behavior stops being surprising and starts being something you can direct.

This covers the rule itself, the four ways to state a move explicitly, what the file system does differently for a move than for a copy, and the situations where choosing move rather than copy has consequences that only appear later.

The rule is about volumes, not folders

Dragging an item to a location on the same volume moves it. Dragging an item to a different volume copies it and leaves the original where it was.

That is the whole rule, and it explains almost every case that feels inconsistent. Dragging from Documents to Desktop moves, because both live on the startup volume. Dragging from Documents to a USB stick copies, because the stick is a separate volume. Dragging from one external drive to another external drive copies, for the same reason.

The design intent is protective. Removable and network storage can vanish mid transfer, and a copy that fails leaves the original intact while a move that fails could leave nothing. The cost is that the safe default is not always the wanted one, and the Finder gives no warning that a copy just happened rather than a move.

Two things make the volume boundary less obvious than it sounds. Disk images mount as their own volumes, so dragging into a mounted image copies even though the image file itself sits on the startup disk. And a Mac with more than one APFS volume in the same container, which is the normal layout, will treat those volumes as separate for this purpose even though they share the same physical space.

To check quickly which side of the line a destination sits on, turn on the path bar with View then Show Path Bar. The leftmost element names the volume.

Four ways to state the move explicitly

The Finder has no Cut command for files, which is the source of a lot of confusion for anyone arriving from another desktop. The equivalent exists, but it is expressed as a modifier on the paste rather than as a separate cut.

Move files to a different disk: Press and hold the Command key, then drag the files to the disk. Source: support.apple.com

The second route is the copy and paste one. Select the file, press Command-C, navigate to the destination, then hold Option while pressing Command-V. The Edit menu item changes from Paste Item to Move Item Here while Option is held, which is a useful way to confirm before committing. The original is removed after the transfer completes.

The third is the terminal. mv source destination moves regardless of which volumes are involved, with no modifier needed and no dialog.

The fourth is dragging with Option held, which does the opposite and is worth knowing so it can be avoided by accident. Option-drag within the same volume copies rather than moves. Option and Command together create an alias instead.

Gesture	Same volume	Different volume
Drag	Move	Copy
Command-drag	Move	Move
Option-drag	Copy	Copy
Option-Command-drag	Alias	Alias
Command-C then Command-V	Copy	Copy
Command-C then Option-Command-V	Move	Move
Command-D	Duplicate in place	Not applicable

The row worth memorising is Command-drag, because it makes the behavior identical on both sides of the volume boundary. It removes the need to know which volume anything is on.

What the file system does differently

Within a volume, a move is a rename. The data does not go anywhere. The directory entry that names the file is unlinked from one parent and linked to another, and the operation completes in the time it takes to write that metadata, whether the file is 4 KB or 40 GB.

Across volumes there is no such operation available. The manual page for mv on macOS states the consequence directly: because the rename system call does not work across file systems, mv falls back to cp and rm, with an effect equivalent to removing the destination path, copying the source with cp -pRP, then removing the source.

Three consequences follow from that fallback.

Time. A cross volume move takes as long as a copy of the same size, because it is one. There is no fast path, and a progress bar that stalls is a copy stalling.

Interruption. If the process is stopped partway, the source is still there and a partial destination may also be there. Nothing is lost, but the destination cannot be trusted until the operation finishes cleanly. A same volume move has no such window, since the metadata write either happens or does not.

Attributes. The -pRP flags preserve modification time, access time, file flags, and access control lists where the destination file system supports them. Where it does not, they are dropped silently. Moving to a volume formatted as exFAT or FAT loses extended attributes, including Finder tags and the quarantine flag, without an error.

That last point matters more than it looks. Finder tags are stored as an extended attribute, so a folder moved to a FAT formatted drive and back arrives with its tags gone.

Replace and Merge are different answers

Dragging a folder onto a location that already holds a folder of the same name produces a dialog, and the options in that dialog depend on the contents.

Holding Option while dragging offers Merge, which keeps items from both folders. Apple's documentation is specific about when that option appears: it shows only if one of the folders contains items that are not in the other. When the two folders hold different versions of identically named files, the only choices offered are Stop or Replace.

Replace is not a merge with preference. It removes the destination folder and puts the source folder in its place, so files that existed only in the destination are gone. This is the single most common way a move destroys work that a copy would have preserved, because the dialog wording reads like a per file question and behaves like a per folder one.

The safe habit when the destination already contains a folder of the same name is to rename one of them first, complete the transfer, then reconcile the two folders as a separate step where the differences are visible. Comparing two folders side by side before merging is one of the things a dedicated file manager does that the Finder does not.

Where a move goes wrong that a copy would not

Aliases survive a move. Symbolic links do not. An alias records a persistent reference and keeps working when its target is moved within a volume, while a symlink stores a path and breaks the moment the path stops resolving. Anything scripted, anything in a development tree, and anything created with ln -s is in the second category.

Files stored in iCloud Drive with Optimize Mac Storage enabled may exist locally only as placeholders. Moving one out of iCloud Drive requires the content to be downloaded first, and the transfer will pause while that happens. Moving a large folder this way can pull down far more data than expected.

Open documents follow a moved file within a volume, since the application holds a reference rather than a path. Across volumes the file is a new file, and an application with unsaved changes may write them back to the original location. Closing documents before a cross volume move avoids the question entirely.

Time Machine treats a moved file as a new file at the destination. A large reorganisation therefore produces a large next backup, which is worth knowing before starting one on a nearly full backup disk.

Keeping guard rails when moving from the terminal

mv overwrites the destination without asking. That is the default and it is silent.

mv -n source destination     
mv -i source destination     

The first refuses to overwrite an existing file. The second asks before each one. For a bulk move where the destination might already hold matching names, -n is the safer starting point, because it completes what it can and leaves the collisions in place for a second look.

For large cross volume transfers, rsync -a --remove-source-files source/ destination/ copies first and removes each source file only after that file has been transferred successfully. It leaves the empty directory structure behind, which is deliberate and easy to clear afterwards.

One naming constraint applies to any destination on a Mac. A colon cannot be used in file or folder names, and names are limited to 255 characters, so a move that also renames can fail on the name rather than on the transfer.

Confirming what actually happened

The Finder reports progress but not outcome. A transfer window closes the same way whether the original was removed or left behind, so the check has to be deliberate.

The fastest visual confirmation is the source location itself. If the items are still there after the progress window closes, a copy happened. This sounds obvious and is skipped constantly, because the natural next action after a long transfer is to navigate to the destination and look at what arrived rather than back at where it came from.

For folders, counting is more reliable than looking. Selecting the items and choosing File then Get Summary Info while holding Control produces an information window per item, and the Finder status bar at the bottom of a window shows the number of items in the current folder along with the free space on the disk. If the status bar is hidden, View then Show Status Bar brings it back. Comparing the item count at both ends catches a transfer that stopped partway more reliably than comparing folder sizes, since sizes can differ legitimately across file systems.

For anything that matters, verify content rather than counts.

diff -rq /path/to/source /path/to/destination

This walks both trees and prints only the differences. Silence means every file present in one is present in the other with identical content. On a large tree it takes a while, because it reads both sides, and that is exactly what makes it worth running before deleting a source that was copied rather than moved.

Free space is the other check. Note df -h before the transfer and after it, on both volumes. A cross volume move should show the destination shrinking and the source growing back once the original is removed. If the source never grows back, the original is still there.

What to change first

Start using Command-drag as the default gesture for anything going to another disk. It removes the need to know where the volume boundary is, and it is the only gesture that behaves the same on both sides of it.

Then, before any move into a location that already has a folder of the same name, rename one of them and reconcile afterwards. Keeping the folder view and the shell in one window makes that reconciliation a single step rather than a switch between apps, which is the arrangement Atriens is built around.