8

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 ;) )?

nohillside
  • 100,768
Samusz
  • 99
  • 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. https://apple.stackexchange.com/questions/12391/why-is-it-not-possible-to-use-the-cut-command-to-manipulate-a-file-in-the-find 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 [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 06: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 07: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 07:28
  • 1
    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
  • @bmike Yes I was aware of paste. Coming back to macOS from nix for more than a decade it seems weird to paste a copied folder (from a USB key for instance) to then "go back" and have to delete the then duplicated files. Was I looking for mv ? It might just be me getting to feel at home again with Finder. Thanks for the comment. About weigh in on the merge* I have no clue as to how, indeed IMSoP's answer is indeed fabulous. A great sum up of how the usability / data safety balance is implemented in the "cut/copy/paste paradigm" and how it's implementation to files has specific concerns. – Samusz Aug 07 '20 at 03:11

3 Answers3

20

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

Saaru Lindestøkke
  • 5,821
benwiggy
  • 35,635
11

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?

IMSoP
  • 242
  • 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
  • @IMSoP excellent answer now, and much more useful than the accepted one. – Eric Duminil Jul 22 '20 at 05:39
  • This is superb. By designing cut/copy/paste to move a file reference, the actual file data remains protected by ACL/permissions, speeds up the operation and doesn’t put all the data included in the file in the paste-board object. Apple’s design gets the job done, securely, efficiently, neatly IMO. – bmike Jul 22 '20 at 07:31
  • @bmike: How is this design different than in Windows/Linux? As far as I can tell, no other major OS actually copies any data during copy or cut, only on paste. ⌘+C & ⌘+V in macOS seems to be just like Ctrl+C & Ctrl+V in Linux, and ⌘+C & Option+⌘+V in mac OS seems to be like Ctrl+X & Ctrl+V in Linux. – Eric Duminil Jul 22 '20 at 10:48
  • Just in case your last question wasn't rhetorical : I think an additional ⌘+X & ⌘+V method to cut and paste files, along the current ⌘+C & Option+⌘+V with the same behaviour, wouldn't be confusing. Depending who the user is, one of the two variations would be used and the other would probably be completely ignored. – Eric Duminil Jul 22 '20 at 14:58
  • @EricDuminil It depends how you think of the existing shortcuts. If you think of it as "⌘+V means copy file, Option+⌘+V means move file", then having ⌘+V mean "move file" after ⌘+X would be confusing. If you think of it as "⌘+V means normal paste, Option+⌘+V means special paste", then Option+⌘+V should probably do nothing after ⌘+X (because there's nothing extra special to do). – IMSoP Jul 22 '20 at 15:08
  • @IMSoP: Thanks for the answer. "Option+⌘+V should probably do nothing after ⌘+X". Yes. But people already using "Option+⌘+V" simply would not use "⌘+X", and people coming from another OS would keep on using "⌘+X" and "⌘+V", without any surprise, and wouldn't care about any other combination for moving a file. It's probably not going to be implemented anyway, so your answer is fine as it is. – Eric Duminil Jul 22 '20 at 15:19
  • I don't agree the metaphor doesn't work. If you simply put the file back where it started (which would be a UI trick) should the paste fail, cut-and-paste would work fine with the usual metaphor, IMO. – Reid Jul 23 '20 at 22:05
  • @Reid The metaphor is that you've "cut the file out" from its original location; there's nothing in that metaphor that allows it to magically reappear in that location if you do something else (it's convenient for that to happen, but it's not consistent with the metaphor). There's also nothing in that metaphor that allows it to continue occupying space in its original container - according to the metaphor it's already gone from there, but that would only be possible if you actually moved the contents into RAM and deleted the original. – IMSoP Jul 24 '20 at 08:17
  • That interpretation seems excessively pedantic to me. – Reid Jul 27 '20 at 17:16
10

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.

Seamus
  • 4,547
  • 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 05 '20 at 00: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 05 '20 at 18:05