I find it weird that this simple functionality doesn't exist in macOS, as it does in other OS. IIRC, it used to exist in the System 7 era.

What would be the rationale to get this simple functionality out of the window (I should say Apple here, I know ;) )?

  • 2
    Not to be pedantic and all but there was no "MacOS7" It was referred to as "System 7" and as @benwiggy indicates: nope. File copy/paste wasn't even in earlier versions of OS X. – Steve Chambers Jul 20 '20 at 22:09
  • 1
    This functionality is present and has been since Lion. apple.stackexchange.com/questions/12391/… To change duplicate, this needs an edit to clarify what problem is being solved other than speculating why Apple did what it did. Ask on Ask Different Meta if the excellent answers here need to be merged into the main thread on copy/paste in macOS / OS X – bmike Jul 22 '20 at 6:55
  • 2
    @bmike Fair enough. I wish "merge" was a more integrated feature in the platform, so it didn't require special pleading, but I'll leave it to others to decide if my answer below is worth rescuing. – IMSoP Jul 22 '20 at 7:19
  • 1
    Your answer is fabulous @IMSoP - just about everything community / elected moderators can do is reversible. Merge can not be easily reversed, so we want to be deliberate and sure there’s consensus. I also want the OP to have a chance to weigh in - were they unaware of paste existing for a decade in macOS when they asked? – bmike Jul 22 '20 at 7:28
  • It is simply not possible because the keyboard shortcut for Cut (⌘X) is not enabled for filesystem items in Finder. You'll need to ask Apple why they have not enabled Cut (⌘X) for filesystem items in Finder. – user3439894 Jul 22 '20 at 12:42

The clipboard metaphor doesn't really work well for files, and while "copy file" can be implemented transparently as "copy and paste", "move file" requires some judgements.

At its simplest, "copy" means putting some data into shared memory, and "paste" reading it back out; "cut" is then "copy" plus immediately deleting the source data.

For working with files, this would be incredibly inefficient - imagine if you selected a 2GB file and pressed "copy", and had to wait for 2GB of data to be loaded into RAM.

So instead, file management programs overload the "copy" command in some way so that what is put in shared memory is just a pointer to the file. They then overload "paste" to run an appropriate "copy file" command. The UI will act as though you've "copied a file to the clipboard", and "pasted it from the clipboard to a new location", but the file content itself is never in the clipboard.

With a straight-forward "copy and paste", this is mostly transparent to the user - the effect is largely the same as if the content was actually placed in memory. It also achieves what the user wants to do: copy the file on the filesystem, with the clipboard just being a UI convenience to do so.

The natural parallel is for "cut and paste" to mean "move file", but there's a problem. Normally, "cut" means "copy and then delete the original", but if the data hasn't actually been copied anywhere, the source can't be deleted yet. The actual "move file" command has to be executed when the user selects the target directory.

However you implement it, some of the expectations of the clipboard metaphor will be broken by any useful "move file" function.

You could special case "cut" to only delete the source content once it's been pasted. "Cut" can place a file pointer in the clipboard with an instruction that when pasted, the "move file" command should be used instead of "copy file". This makes "cut and then paste" work as expected, but if you look at the original file, it's still there until you paste it, which wouldn't be true if you "cut" any other type of data. This is how Windows Explorer works, for instance, and it tries to indicate the "cut but not deleted yet" state by rendering the file's icon transparent while it's "in the clipboard".

As a variation, "cut" could move the file to a temporary location, so that it is immediately removed from its original location. On many file systems this can be done with practically zero cost as long as the temporary location is on the same partition, by editing two directory entries. Then on paste, move the file from the temporary location to the target. This would make the file disappear immediately when "cut", but the user may still notice that "paste" is doing the actual move - for instance, a large file which has been "cut" will still take up space on its original partition. (I don't know if any OS / file manager uses this approach.)

Alternatively, you can offer the user a special "paste" operation which deletes the original. This makes it clearer that the source file has not been removed yet, but means that the "copy" command might result in deleting the source file, which would not be true of any other data. This is what MacOS Finder makes available: after copying a file, the user can choose to move it by pressing Option+Command+V instead of Command+V.

Although these approaches all need some of the same implementation, it would be confusing to offer more than one variation. For instance, if MacOS allowed you to "cut" a file, would Command+V do the same thing as Option+Command+V? Or would one of them be unavailable?

  • 1
    Of course, in a Unix filesystem, you never delete files anyway. You add or remove name entries in directories, and a file will simply be "garbage collected" if there are no more names pointing to it, and there are no more open file handles to it. So, you could use this behavior in the implementation: "Cut" puts a file handle into the clipboard and removes the directory entry. "Paste" creates a new directory entry and releases the file handle. – Jörg W Mittag Jul 21 '20 at 18:01
  • @EricDuminil That is not true. Copy certainly does copy; cut moves. What you may be overlooking is that it copies/cuts to the clipboard. – Harper - Reinstate Monica Jul 21 '20 at 19:25
  • 1
    @EricDuminil Yes, that's what I tried to put across in this answer: "copy" and "paste" already stretch the clipboard metaphor when it comes to files; "cut" would have to stretch it a little bit further, and on Windows does so. On MacOS, they've made the arbitrary decision to stretch "paste" instead; neither is particular "right" or "wrong", and no OS would actually want to implement "cut and paste" the same way for files as for other data. – IMSoP Jul 21 '20 at 19:29
  • 1
    @Harper-ReinstateMonica With files, "copy" doesn't actually do the copying, "paste" does. That's why MacOS can implement "move" as an alternative paste action, because "copy" just means "remember this file, I'm going to ask you to do something with it soon". – IMSoP Jul 21 '20 at 19:31
  • @JörgWMittag I've expanded the answer to cover the extra option that that makes possible, and why it still doesn't solve all the issues. – IMSoP Jul 21 '20 at 21:15

Because the Pasteboard, to which all data is Cut, is inherently transient and unsafe. If you could Cut a document in the Finder, that document would only reside in the Pasteboard, and any new Copy/Cut action would cause it to be lost.

You could never Cut a file in Pre-OS X Mac operating systems.

However, you can achieve the same result by Copying (CMD+C), and then Moving (Option+CMD+V).


Insofar as files are concerned, "cut and paste" is "move" by a different name. With Finder, as you have likely noticed, there is a rule behind its behavior during drag-and-drop operations on files:

drag-and-drop to the same volume: move is default.
drag-and-drop to a different volume: copy is default.

But if these default behaviors are not what you want, here's how to modify that:

Command key while dragging changes copy to move.

Option key while dragging changes move to copy.

If you find it tedious to remember this, one option is to use mv or cp from the CLI.

  • 2
    It's good to know. The drawback with drag and drop is that you need to be able to access the two locations in the finder with the mouse. – Eric Duminil Jul 21 '20 at 20:16
  • I suppose, but you can make that much easier with tabs in Finder. – Seamus Aug 5 '20 at 0:16
  • indeed. You still need to prepare the tabs before you drag and drop, though, as opposed to copying a file and maybe pasting/moving it later, at any location you'd like. – Eric Duminil Aug 5 '20 at 18:05

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