From http://boards.straightdope.com/sdmb/showthread.php?p=11944694#post11944694
“And a word of warning, if you happen to be on a Mac: the Finder does not have this folder-merging behavior. It treats folders the same as folders when copying, in that it replaces instead of merges. (There are some good reasons for this, but that’s another thread”
So what happens to any files that the destination folder had that the source folder didn’t?
And what are those ‘good reasons’?
So that when you copy a folder you actually get identical copies instead of some wierd melded thing that happens to have the same name as the folder you wanted a copy of, but may also contain dozens of orphaned files that you may later have trouble figuring out where the heck they came from?
So if you have a folder called ‘photos’ on c: and a folder called ‘photos’ on an external drive. And you want to update your c:\photos folder, so you copy the folder from your external drive to your c:\photos folder and promptly lose all your old photos.
Makes sense.
Not without a warning in Big Friendly Letters.
The sensible way to do that, of course, is to copy the actual photos in one folder to the destination folder.
The name of the application is “Finder” – not “the Finder.” (For some reason “the Finder” and “MAC” in all caps is prevalent!).
The good reason is that a copy is a copy. It meets all expectations of what a copy should be. Windows sometimes frustrates me when I accidentally merge folders without it being expected. Granted, sometimes I’d like to merge a folder on the Mac, the Windows way. All in all, it’s less destructive if you make a mistake on the Mac versus having to do it manually in Finder, which is the “Mac way” (do no harm). If I have a lot to merge, I’ll just drop to the shell, which isn’t the “Mac way” but luckily I’m also smart so no harm done.
Doesn’t it? If I want to copy a folder, then I want a COPY of THAT folder.
I don’t copy a folder so that I can merge files into a folder. If I want to merge files, then I should be moving/copying FILES.
And there is a warning whenever a folder/file move would delete the old version.
(PS: Don’t read this as being snarky. I understand that once you get used to one behavior, anything different can seem counter intuitive. But the bottom line is that Apple puts a very high priority on making features intuitive to people who are not already familiar with computers. Power users like me can always learn to use rsync from the command line, or download a free shareware application for merging/syncing folders.)
Just tried this in Unix to see the behavior to see if Finder was following Unix behavior:
Created files:
foo/alpha
foo/beta
foo/gamma
bar/foo/one
bar/foo/two
bar/foo/three
then ran “cp -r foo bar”
The results: Folder “bar/foo” was replaced by “foo”.
So, Mac OS X is merely following Unix behavior. Considering that Mac OS X is based upon BSD Unix, this should be expected.
However, there may be another reason why copying one version of a folder to another one will replace the other one. Some files, like the Applications, which are represented as a single file in the Finder are actually not files, but folders.
In Mac OS X, these are referred to as packages. If you have the Terminal application (it is under the Utilities folder in the Applications folder), open it, and type in the following:
cd /Applications ls
Now, open a Finder window and go to your Applications folder. You’ll see that the Terminal window and the Finder Window will show identical folders and files. Now, in your Terminal window, do this:
cd Safari.app
ls
Contents
cd Contents
ls
CodeResources Safari Webpage Preview Fetcher
Info.plist SafariSyncClient.app
MacOS WebApplicationCore.bundle
PkgInfo _CodeSignature
Resources version.plist
In Unix, the “cd” command means “change directories”. Thus, the Safari application is a folder that contains a bunch of files that Safari needs in order to run.
If you right click on the Safari.app icon in Finder, and select “Show Package Contents”, you’ll see the same thing.
Now, imagine I have an App called Fetch that is at version 4.3 and I want to replace it with a newer version of Fetch which is at version 5.1. In Finder, I drag the version 5.1 Fetch application into my Application folder and the newer version of Fetch will overwrite the older version of Fetch.
Since both of these applications (the 4.3 version and 5.1 version) are folders, the last thing I want is for the 5.3 version of the application (which is just a folder that contains program code to execute and other resource files) to merge with the older 4.3 version of the application.
Therefore, Finder has to replace a folder when you copy a new version and not merge them.
I hope this makes sense.
The Mac System was behaving this way since long before it had a Unix kernal.
IIRC, System 1.0 worked this way back in 84.
I could haul out my “Macintosh” and check, but it’s way in the back of the closet, and I’m not sure where I keep the 400K floppies for it.
The Mac’s copy behavior probably arose from the literal application of the desktop metaphor as described in the Macintosh Human Interface Guidelines.
Switching the meaning of a command between copying and merging depending on context, and without letting the user know, has a very Microsofty feel to it.
Although the Finder (forget it Balthisar, I’ve been in the Mac business for 25 years, and no one has ever or will ever call it just “Finder”) may emulate Unix behavior, it has worked this way since the Mac 128K days, long before the OS was Unix-based.
Yes… but you could work around this. The Microsoft solution would be to write a whole bunch of extra code to see if a folder was also an application and then change the “default” behavior yet again.