Move Command To Move Files?

wayne lau

Hi,



I've noticed that in OSX 10.3.2 (and the versions before it) you can't seem to cut and paste files with hotkeys in Finder (in fact there's not even a move command). You are allowed to copy and paste obviously with cmd-C and cmd-V, but is there a reason why a MOVE feature was not supported?



Anyone know a workaround for this other than dragging files around?



Thanks

madmax559

Quote:

Originally posted by Wayne Lau

Hi,



I've noticed that in OSX 10.3.2 (and the versions before it) you can't seem to cut and paste files with hotkeys in Finder (in fact there's not even a move command). You are allowed to copy and paste obviously with cmd-C and cmd-V, but is there a reason why a MOVE feature was not supported?



Anyone know a workaround for this other than dragging files around?



Thanks

cmd + x ... i think....if they have implemented the cua

guidelines

pbg4 dude

You could use the 'mv' command in the terminal but that's probably not what you want to hear. Maybe you could write an Applescript (or shell script) to implement this feature? I know for certain that CMD-X doesn't work.

ghost_user_name

Quote:

Originally posted by Wayne Lau

is there a reason why a MOVE feature was not supported?

It has been long debated that the copy/paste/cut metaphor for files is inherently flawed. The cut operation is completely inconsistent with how cut works everywhere else. I'm sure a couple of google searches will get you some explanations.



In brief, cutting implies that you destroy the original and a copy is left on the clipboard. Windows screwed up this definition when Microsoft added the cut functionality for files. How do you define it now? You can't in a way that is consistent with the rest of the system. Say I cut File A. The original should be destroyed or hidden until I paste it. Now I cut File B. What happens to File A? Does is go "poof" and disappear like a text or picture clipping would on the clipboard?



There are lots of scenarios that people have tried to work out. It's all an ugly mess and only works if you completely redefine how that operation works for this special case. Inconsistency like this is very bad from a design standpoint and I suspect this is why Apple chose not to implement it.



That explains why cut isn't there, but it doesn't answer your actual question about a "Move" command. My only guess is that it too would be a mess from the users' perspective, like the cut operation.

chych

So don't call it 'cut', call it 'prepare for move' or something, no breaking of metaphors there. I think it is damn convenient and should be in finder.

welshdog

Quote:

Originally posted by Brad

My only guess is that is too would be a mess from the users' perspective, like the cut operation.

Seems like CNTL click on a file could offer a menu selection to "move" or "transfer" a file. The result would be a window where you select a destination. I dunno that may be too much like Windows.



A more likely choice might be the Services menu selection in the Finder. "Move" would be a good candidate for adding there IMHO.

wayne lau

Thanks for the replies and input everyone.



I guess I understand Apple's would-be reason for not implementing a move type command.



I think there's a utility out there called "Move Items X" that actually implements a move feature into the contextual finder right-click menu. I'll go check it out n see.

matts

To move a file in OS X from disk to disk, you drag the file where you want it (the cursor showing a + sign) and then you press Command and let go: the file, folder etc is then copied to the new location and then erased from the original location.



If something goes wrong _while_ all this is going on... better stick to copying stuff?



Matts

chych

Well, the data is only removed AFTER it has been copied, successfully. Cmd + drag isn't as useful as 'cut' since you would need two windows; with cut, only one window is needed.