Once upon a time, the Finder’s behaviour followed a simple set of rules when dragging files around between open windows. As macOS has become steadily more complicated, those rules have also become more elaborate. What might seem to you to be predictable and instinctive sometimes behaves surprisingly. Let me explain from the beginning.

Basic behaviours

The original behaviour of the Finder when you drag a file between two windows depends on whether they show views of the same volume.

Within the same volume:

• dragging a file moves it between folders;
• Option-dragging a file copies it between folders, leaving the original where it was;
• Command-dragging a file moves it between folders, removing the original.

Between different volumes:

• dragging a file copies it between volumes;
• Option-dragging a file copies it between volumes, leaving the original where it was;
• Command-dragging a file moves it between volumes, removing the original.

In addition to those, if there’s a clash of names on the destination, such as moving/copying the file Test1.text to a folder where there’s already a file of exactly the same name, then a dialog is displayed inviting you to decide whether to keep both files, stop the action or replace the existing file with that being moved/copied.

Those are consistent, and apply regardless of the file system on the volumes, so long as they’re both local to that Mac, that is they’re inside it or directly attached to it.

When support was added for networked shared volumes, provided that they’re mounted with sufficient permissions for you to both read and write, they behave the same as different locally attached volumes, maintaining orderly behaviour.

iCloud

When Apple introduced cloud storage in what has evolved into iCloud Drive, it could have opted to treat it as a networked shared volume. Instead it opted for the illusion that it’s just an extension to that Mac’s startup volume. This means that its behaviour differs according to where you’re dragging the file from. Take it from or to your startup volume, and it behaves as if it’s within the same volume; take it from or to another local volume, and it’s now a different volume.

As someone who regularly works from folders on both my internal boot SSD and an external working SSD, I’ve become used to holding the Option key whenever I want to copy a file to or from iCloud, so I don’t have to worry whether the drag involves the startup volume. Even then I’m left a little confused by the behaviour of iCloud Drive. Perhaps that’s just my age.

AirDrop and dropboxes

Apple introduced AirDrop over ten years ago, and brought with it another set of behaviours which conform to a dropbox pattern (not the Dropbox service). In this, every drag and drop is a copy, no modifier keys can alter that, and name clashes are dealt with automatically by renaming the new file, e.g. from Test1.text to Test1 2.text.

That works well for AirDrop, which is a blind transfer service saving received files in the Downloads folder. This dropbox behaviour also applies to files dragged and dropped under Universal Control, between Controller and Target Macs, which perhaps isn’t as intuitive. In this case, the user has full view and control over the destination, just as they do when moving/copying to/from an external volume, just on a different display. In spite of appearances, modifier keys can’t change the copy into a move, and name clashes are automatically resolved by renaming. You can’t use a file drag and drop to replace a file on either Controller or Target.

Complications

Now, armed with the above, tell me what happens when, using Universal Control, you drag and drop a file from a shared volume connected to the Target Mac from that Target onto the same folder on the Controller Mac’s local volume, where the original file is? Will you see the normal Finder warning of the name clash, offering to keep both, stop or replace? Or will the file be copied and renamed automatically as a duplicate?

To step through this in detail, you need two Macs, one the Controller, with File Sharing turned on, and the other the Target, which you connect to that shared folder on the Controller Mac. Using the mouse/trackpad connected to the Controller, move the pointer to the Target Mac’s display, select a file in the shared folder, and drag it back over to the Controller’s display, there dropping it on the same folder from which the file came, this time on a volume which is local to the Controller.

The correct answer is that the file is copied from the shared folder to itself, and automatically renamed to avoid the name clash. It effectively duplicates the original file, but doesn’t actually duplicate it in an APFS sense, which brings me on to the real complications: APFS clone and sparse files.

APFS clone files and copies

Clone files are a valuable feature of APFS, as they save storage space, enabling you to keep and to work on copied files which occupy the least space required. Cloning can only work within the same volume, though, in spite of the fact that APFS volumes share the same space within a container.

macOS tries to make a clone when a file is copied or duplicated in the Finder to a location on the same volume, and when copying/duplicating many shallow and simple folders. As it’s almost impossible to discover whether any file is merely a clone, this is hidden completely from the user. iCloud doesn’t appear to be able to preserve clone files, though.

APFS sparse files

Sparse files are another important feature of APFS, as they allow apps to store what might otherwise be huge and largely empty files extremely efficiently. Rules for their creation are even more obscure than for clone files, in that the app writing them has to make specific calls to the macOS API. At least they’re easier to identify, by the great disparity shown in Finder’s Get Info dialog between their stated size and the size taken on disk.

At one time, handling of sparse files wasn’t good across macOS, and they could easily explode to full size when copied outside the volume on which they had been created. Apple has addressed that now, and they’re usually preserved in their sparse form when copied to other APFS volumes, and even to iCloud Drive. However, they will invariably explode when copied to HFS+, which doesn’t support the sparse file format.

Exceptions

Recent changes in boot disk structure have brought a confusion of exceptions, some of which are consistent with previous behaviours. Drag an app from the Applications folder to your Data volume, and you’re likely to get an alias to it. Although that might make sense for an app locked on the System volume, it’s yet another behaviour to catch you out. Holding the Option key should make a copy, as will dragging it to a different volume. This can also become confusing when dealing with folders which are firmlinked between System and Data volumes.

By now, I’m sure you’ll have realised that there’s no succinct summary of all the behaviours that can result from simply dragging a file between windows in the Finder. I may have to think about offering a one-day training course instead.