Evil OS X Key Combo
I just discovered that there is a key combo in OS X to *move* a file (not copy it) from an OS X server share point to another volume. This combo basically moves the file (copies it over) to the destination and then deletes the original from the source. This key/mouse combo is:
Command + drag file(s)
This key combo is NOT documented by Apple at all (that I can find). It is very dangerous. I cant belive I have never seen this action before.
Try it:
1) Go to a mounted AFP share point.
2) Click a file or folder (highlight it in the Finder)
3) Strike the Command key while dragging the file(s) to another location (for example- another share, your hard drive, etc).
Poof! The file will be moved and then the original will be deleted (without any server-side warning message or dialog box). The OS X Server logs will naturally record the move action as a "Delete" action. Misleading, but understandably so I guess.
Question: Is there a way to disable this key combo in OS X so that users can't accidently (or otherwise) us this key + drag combo?
Command + drag file(s)
This key combo is NOT documented by Apple at all (that I can find). It is very dangerous. I cant belive I have never seen this action before.
Try it:
1) Go to a mounted AFP share point.
2) Click a file or folder (highlight it in the Finder)
3) Strike the Command key while dragging the file(s) to another location (for example- another share, your hard drive, etc).
Poof! The file will be moved and then the original will be deleted (without any server-side warning message or dialog box). The OS X Server logs will naturally record the move action as a "Delete" action. Misleading, but understandably so I guess.
Question: Is there a way to disable this key combo in OS X so that users can't accidently (or otherwise) us this key + drag combo?
Comments
"CMD Z"
This will undo the move (even a move to Trash or from volume to volume).
Originally posted by dstranathan
This key combo is NOT documented by Apple at all (that I can find). It is very dangerous. I cant belive I have never seen this action before.
http://docs.info.apple.com/article.html?artnum=75459
If you drag and drop a file within a volume, it moves it, right?
Cmd-drag-and-drop turns that into 'copy'. Been like this for, well, years.
Now here's the wacky part: if you drag and drop a file from one volume to another, it copies, right?
Cmd-drag-and-drop turns that into 'move'. It reverses it.
Personally, I'd like to see 'move' be across the board the same, no matter what volume it's on, or going to, and Cmd- be the modifier to copy. I can not tell you *HOW* many times I've tried to explain this to users, and they look at me like I'm insane that they have to remember which folders are on which volumes to anticipate whether a drag and drop will copy or move. Optimally, you'd work with them all the same way, but... *shrug*
The cursor change is not "subtle", at least not in a bad way. I see the opposite effect all the time when I make additional copies inside one disk with Option-drag. It's very obvious.
If you need to protect the files against accidental move, you want backups, version control, or just plain adjusted rights on the file.
Originally posted by curiousuburb
The default volume-to-volume transfer should be copy, not move, in part since it is common to have a read-only volume as the source (ie. CDROM) and if move were the default, you'd get errors every time you installed software or OS from read-only media, wouldn't you?
If read-only: copy
If read/write: move
Now you have exactly the same situation as dealing with a local volume for which you have read permissions only. Nothing new to learn. The idea is to make the number of things the user has to keep track of at a minimum. Knowing the permissions on even a local volume is necessary, so why not extend that to remote volumes?
Originally posted by curiousuburb
The default volume-to-volume transfer should be copy, not move, in part since it is common to have a read-only volume as the source (ie. CDROM) and if move were the default, you'd get errors every time you installed software or OS from read-only media, wouldn't you?
No. It's right the way it is. Basically it's just doing whatever is the more likely action the user wants to take. Say you are moving a file around on your computer from folder to folder, or even to a different place in the folder, it is more likely that you want to move it than copy it. However if you are moving between volumes (such as: copying an assignment onto a cd to bring to class, making a backup, or some other volume transfer) than it is more likely that you want to make a copy and keep the origional.
The only place where it could get confusing, is if you have multiple permanent hard drives, where it would by default copy between them (which might seem to be an exception for novice computer users.) But this is uncommon for such users to have multiple hard drives anyway, so it really isn't an issue.
Originally posted by Kickaha
Here's what you're seeing:
Cmd-drag-and-drop turns that into 'copy'. Been like this for, well, years.
Um... the option key enables copy mode. I assume that's what you meant.
In either case, I still think that the default for drag and drop should be move, regardless of what volume is the target or source. As networked volumes become more ubiquitous, the entire concept of having to keep track of where the file is coming from or going to is going to seem... quaint.
However, when you want to make *a copy*, you generally know that in advance, and know that you are doing so. ie, make a *copy* onto a CD-R, or make a *copy* onto removable media like a thumbdrive, make a *copy* of that file from the remote drive to your local one. Copying is a conscious choice, and not the norm in my experience.
*Moving* files will become the norm as our storage becomes more decentralized, and we treat it all as one big drive. Imagine how much of a pain it would be if your hard drive was partitioned into a dozen smaller volumes, and you had to keep track of which drag and drop would make a copy, which would move, and all those spurious copies floating around... well, that's where we're going to be not too long in the future.
The read/write permissions issue is orthogonal to the local/remote volume issue. Still have to deal with it even on one drive, where permissions can bite you. Drag a file from someone's Public folder, where you have read but not write, and voila, you get a copy.
Then you can't figure out which folders have copied over entirely, and which haven't, and you now have two sets of folders which aren't complete and don't match up?
I've never been able to figure it out...
Originally posted by Messiah
The problem is where you move a group of folders, and it stops half way through because there is a problem.
Then you can't figure out which folders have copied over entirely, and which haven't, and you now have two sets of folders which aren't complete and don't match up?
I've never been able to figure it out...
yeah if it's very large i copy, verify and then delete.
Originally posted by MacCrazy
yeah if it's very large i copy, verify and then delete.
Wise.