I don’t have as much time with it as I’d like, but over the last six months or so I’ve grown to like OS X. It’s slick, easy to use and generally just gets out of my way, and I keep finding neat little tricks I don’t expect (like dragging the icon on the title bar of the current window to create a shortcut to the document you’re viewing - nice).
However, today something about it had me swearing like a trooper. I’m actually surprised I haven’t come across it before, but the crux of the matter was the behaviour of Finder when you copy a folder into a location which already contains a folder of the same name. In Windows Explorer if you answer ‘Yes’ to the confirmation dialog the contents of the folder you’re copying will be merged into the destination, only overwriting files of the same name. Finder conversely will completely replace the copy of the folder that is currently there, deleting its previous contents and replacing them with only the contents of the source folder you’re copying. I managed to completely screw my Eclipse install this way (which I use for Java dev sometimes) by copying ‘features’ and ‘plugins’ folders from a plugin archive, which ended up excising every previous plugin and feature that was already in there, including the core. Gah.
In fairness, the prompt that comes up does ask you whether you want to replace the folder that’s there. However, having been conditioned on Windows, I interpreted that in the non-literal sense to mean ‘merge’ and answered in the affirmative, little knowing that it really did mean ‘replace’. Unfortunately the replaced content doesn’t end up in the Trash either, so I had to reconstruct my Eclipse install from scratch. Once again, gah. Luckily it didn’t take that long since it kept all my automatic remote plugin sources, it’s only manually installed plugins like this one that needed re-doing.
I guess it’s arguable that the reason for my confusion was that I’m just used to Explorer’s interpretation of ‘replace’ to mean ‘replace files in folders’ and not ‘replace entire folders’. I’m therefore not going to suggest that this paradigm is necessarily wrong and should be changed to match Windows - in fact I’ll acknowledge that semantically it’s an accurate description of the operation. However I do think that not providing a merge option is a serious oversight in Finder, since it’s very common to want to do this. Simply including a third option called ‘Merge’ in the confirmation dialog which currently just says ‘Replace’ or ‘Stop’, would serve a dual purpose - indicating to users familiar with other OS’s what the true meaning of ‘Replace’ is in this context, and also allowing you to perform an operation that is after all very useful. OS X prides itself on how obvious and direct most operations are and on the whole it succeeds, but in this case, the ease with which a simple misunderstanding can cause permanent data loss is unacceptable to me. Come on Apple, you can do better than that.
February 14th, 2008 at 5:00 pm
You make a good point about how replaced files(Windows and OSX) should end up in the recycle/trash bin. At the very least it could be a checkbox option in the move/copy and replace dialog.
February 14th, 2008 at 6:03 pm
I couldn’t agree more. The OSX behavior in this case is beyond retarded. That the default operation differs from every other operating system, from its own command line version (mv), and is irreversibly lossy (unlike deleting, it doesn’t put the overwritten contents in the trash bin), is so utterly and completely stupid that it overwhelms me.
The two work around are to just use the command line (how retro!), or use the file merge utility included with OSX (which can merge folders as well). Just browse in finder to /Developers/Applications/Utilities/ and drag the icon for FileMerge to the finder windows toolbar (let it hover for a second or two and then drop it). You should now have a shortcut in finder to launch filemerge and you can then drag the two folders you want to merge into it. Ugh. It’s so sad to say that Windows does this SO much better.
February 14th, 2008 at 6:20 pm
It’s a little ambiguous above. I meant that the command line version (mv) doesn’t actually let you overwrite the entire directory like that even if you try to force it (-f).
February 14th, 2008 at 6:29 pm
My guess is that this is a behavioural hangover from Mac OS 9 and before, which of course doesn’t match with tools inherited from other sources. A halfway house of offering a ‘Merge’ button in that confirmation dialog definitely seems the natural solution to me, although I know Apple prefer not to encode variant behaviour in dialogs particularly, they prefer a direct interface idiom. I’m not sure what that would be though.
February 15th, 2008 at 3:40 am
I’m a very happy user of Directory Opus. I go nuts when I have to use plain explorer. Although I like osx finder overall better than explorer, dopus kills them both
February 16th, 2008 at 1:05 am
This is why rsync has become my best friend!! I didn’t catch on to this drag and drop and replace behavior until after a few tries when i first started using OS X. I lost much hair until I figured this one out myself.
February 16th, 2008 at 8:07 pm
[...] was recently reading Steve Streeting’s (aka Sinbad) blog and he resurfaced a valid point about OS X’s Finder that had long annoyed me as well. In [...]
February 16th, 2008 at 8:11 pm
I’ve decide that I wanted to solve this matter once and for all. I’ve created a plugin for Finder that will solve this problem for good.
February 17th, 2008 at 7:46 pm
Cool, thanks
March 9th, 2008 at 8:33 am
Yeah… I learned that hard way on this one too. I also feel like this is the worst “feature” in OSX. At the very least there should be an option to have File Merge on as the default option, or run in a “Classic” file over right version. The fact that you can’t undo is horrible.
Its hard for me to believe that Apple can be so smart and have a feature like this which is so bad.
It reminds me of how the amazinly stupid the Font tool in Windows XP and Windows Vista is because its the same as the Font tool from Windows 3.1