Mac Finder Copy Not Flawed, Just Different From Windows

We received several emails regarding last week's OS X Finder Copy Flawed email from Robert Templeton. We're posting all of these today, and we'll be looking at other issues (old floppies, pivoting screens, and other computer questions) in tomorrow's mailbag column. - Tip Jar

• Replace Does Not Equal Merge
• Finder Copy Different, Not Flawed
• File Managers for OS X
• Templeton Responds

Replace Does Not Equal Merge

From Guy

What this user is describing is the normal Finder behavior when replacing a folder with a second folder of the same name: The contents of the original folder are obliterated and the contents of the second are retained.

Windows default behavior is different. Windows merges the contents of the two folders. He is complaining that Macs do not behave exactly like Windows in this instance.

Macs have been handling folders this way since day one with very little customer complaint, so there is really little motivation for Apple to "fix" it.

The user describes "wiping out a complete dataset from an application", which implies he was making changes within OS X packages. That is a not a place for people who don't understand basic platform file manipulations to be fiddling around. He also chose to ignore the warning dialog asking him if he wanted to replace the folder. Replace does not equal merge.

It is important for users to know how their tools work before they start monkeying with things that could break their system.

Thanks, Guy.

Finder Copy Different, Not Flawed

From Grant Jacobs:

Charles Moore,

Could you please forward this to Robert after you're have a peek over it?

Charles, I'm very surprised that you encouraged Robert to believe that replacing files on copying is a flaw. It isn't; its been the standard behaviour of file copying "since forever".

The software Robert is using seems to have integrated a higher-level operation, one-directional file merges or synchronisation over and above copying.

If there is a bug, its with Robert not learning how things work before going ahead and doing things. Sorry for your bad luck, Robert, but we all get bitten by that occasionally if we act before learning. As painful as it might be, its very rarely the developers fault and almost always a case of not learning first.

There is nothing flawed about copy and replace (incidentally, the Finder does ask before replacing newer files); it's just you assumed that one of several possible ways of moving files from a source to a destination is "the way it ought to be". None of them are more "right" than the other. The real problem lies with knowing the defined behaviour, which brings us back to learning before doing...

There are many cheap and some free programs to do one-directional "file merges", as you call them. In fact, there is even an Automator script on Apple's website (caveat: I haven't tried it). One I have tried is Synk (yes, that's with a 'k'). Many other backup utilities also provide this function.

Even these "file merge" programs can have their problems. One I ran into while quickly testing these was that almost all of them will overwrite a file of the same name but different type in the destination, even when backup options are on. For example, in most of these programs if you do a merge with a "backup replaced files" option on, if you try merge a file onto a folder of the same name, the folder will be replaced but not backed up and thus lost. I presume they share this flaw as most of these program probably use the Unix rsync program internally, which until very recently also has this flaw (Apple's version still doesn't at the time I'm writing).

Grant

Hi Grant,

Thanks for the Information. Data loss for whatever reason is usually traumatic. Given the relatively large number of Windows users switching to Macs these days, perhaps Apple ought to provide some sort of heads up as to major UI differences that could result in the sort of thing that happened to Robert.

I use ChronoSync for backups and file merging, and it works well.

I've forwarded your letter to Robert.

Charles

Editor's note: I've been using File Synchronization from Nemesys Software, which lets you create predefined synchronization sets and determine whether they merge date in one direction or both directions, and even whether they delete files that exist in only one of the two folders. dk

• Synk
• ChronoSync
• File Synchronization

File Managers for OS X

From Egil Helland:

Hi there,

Just read your reply to Robert Templeton about the OS X Finder and alternatives. It looks to me that you misunderstood what Robert was asking, that is if I understand him correctly :). He writes about Directory Opus, which IIRC is a clone of the old Amiga tool with the same name. The Directory Opus is not meant to be a PIM, but rather a powerful file management tool, like Finder on stereoids!

With regards to better Finder implementations as Robert asks for, I would suggest looking at Path Finder from CocoaTech [link below], a very nice tool that can totally replace the Finder (I mean, litterally). The features are too numerous to list, and it has gotten it's share of rave reviews in the past.

Best regards,
Egil

Hi Egil,

Yes, as I mentioned in my reply to Robert, I had no experience with Directory Opus, and indeed my only knowledge of it was his brief description.

In a follow-up letter, Robert wrote: "I did find something called PathFinder during my search, but it doesn't currently have a copy with merge (though the author noted that it may be a feature in future)."

Charles

• CocoaTech

Re: File Managers for OS X

Hi Charles,

Good to hear that it's sorted out. Just a follow-up tip from my part - whenever I need merge functionality I tend to use one of the many Synchronization utilities, preferring Synchronize Pro X and Chronosync myself. They get the job done with minimum fuzz. Very nice when you need to merge directories, for instance from a USB disk and your laptop.

Cheers,
Egil

• Synchronize Pro X

Templeton Responds

From Robert Templeton:

Guy wrote:

"What this user is describing is the normal Finder behavior when replacing a folder with a second folder of the same name: The contents of the original folder are obliterated and the contents of the second are retained. Windows default behavior is different. Windows merges the contents of the two folders. So he is complaining that Macs do not behave exactly like Windows in this instance. Macs have been handling folders this way since day one, with very little customer complaint, so there is really little motivation for Apple to 'fix' it.

"The user describes 'wiping out a complete dataset from an application', which implies he was making changes within OS X packages. That is a not a place for people who don't understand basic platform file manimpulations to be fiddling around. He also chose to ignore the warning dialog asking him if he wanted to replace the folder. Replace does not equal merge.

"It is important for users to know how thier tools work before they start monkeying with things that could break thier system."

I am complaining that Mac OS doesn't behave similarly to other OSs in this instance (not just Windows, by the way).

1. I did not start on Windows. I started computers twenty years ago on a Commodore 64, moving to Amiga, moving to MS-DOS, then to Windows. Have also worked on *nix systems as well and other weird ones like BeOS, LegOS, PalmOS (etc.). None of this behavior was similar to Mac OS. Please don't talk down to me.
2. I understand 'basic platform file manipulations'. Read 1 and add that not only do I build my own computers (hardware, firmware updates, BIOS configuration, OS installation and configuration, and software installation and configuration), I am a computer developer/programmer for those same twenty years. I knew full well what I was doing.

Here, to explain: Curious Labs (now e-Frontiers) Poser is a 3D figure application which I use (and write plugins around). It stores its data in a folder (on both systems) called 'Runtime'. This data comprises texture images, Wavefront OBJ geometry, and Poser files used to define and change content. This is a standard folder hierarchy structure used by Poser for over ten years.

Poser Installation Folder

Runtime

Geometries

filled with folders containing Wavefront OBJ files

libraries

Camera

Characters

Face

Hand

Light

Pose

Props

textures

filled with folders containing images

Each of the 'libraries' folders contains more folders of content. When you receive, say a .sit or .zip archive, it contains a full hierarchy so that files are placed in the proper places during extract: OBJ files go into "Geometries:GGGG:...", textures go into "textures:TTTT:...", Poses go into 'libraries:Pose:PPPP:....", etc., where the repeating letters represent whatever folder naming convention the content creator used for storing the data. Now, when you unarchive or copy the new data into the current data set, it will not merge (as experienced elsewhere), but delete the data and replace it with the new data on MacOS (and only MacOS).

Yes, I ignored the warning (the first time and to my detriment) as on Windows data is replaced, not entire folder structures in such circumstances. Replacing same-named files (such as updates) is to be expected, even on Windows. Not replacing an entire folder structure, deleting existing data, because there are some folders similarly named.

I think that Apple needs to make such differences clear and upfront for users of other operating systems, not just Windows.

Grant Jacobs wrote:

"Charles, I'm very surprised that you encouraged Robert to believe that replacing files on copying is a flaw. It isn't, its been the standard behaviour of file copying 'since forever'...."

Not to my experience in the past many years. On Mac OS, this may be standard procedure, but I have only encountered it in these circumstances on this OS.

"The software Robert is using seems to have integrated a higher-level operation, one-directional file merges or synchronisation, over and above copying."

Funnily, Poser started as a Mac OS application (when it was a product of MetaCreations). And, as I stated above, this has been their standard folder hierarchy for the entire time. This is even evidenced by the fact that when Poser was ported to Windows, they retained the Mac Resource as a 'real' file with extension .RSR, one supposes to avoid making sweeping changes to the existing codebase.

There are no special facilities in the application for adding content. Content is either in 'installation executable' form (i.e.: DMG or EXE) or, more often, in an archive (i.e.: SIT or ZIP - or RAR even) which retains the folder hierarchy.

Grant, I don't agree with these assessments. I did not expect the 'replace' on Mac OS to be completely different than the replace on 'Windows' (or AmigaOS or any other OS that I've used) - which usually means replace same-named files. It is Apple's fault for employing a standard not used by many other OSs. Maybe Unix does this if using certain commands, but I have never had the experience of moving folders around even there and it removing the existing data because the folder names were the same. Maybe it's me, but have any of you ever used another OS other than Mac OS?

And it is a problem if there is not one option for 'Copy with Merge' in the OS. Please show it to me if one exists. I find it funny that you talk about 'merging' folder hierarchies as if that is some esoteric operation. It has been standard practice on Windows and MS-DOS since I can remember. And AmigaOS since I was wee little computer newbie. This is why the result of the clicking "Yes" to replace was so shocking. Nowhere did it warn me that it was going to delete all of the existing data in the process!

Final thoughts here: I'm not a newbie and not someone who doesn't 'learn the tools'. Why, I have a copy of David Pogue's "The Missing Manual Mac OS X - Second Edition" sitting right here in front of me - which I had gone through pretty extensively when I opened up my first shiny Mac G4. And a rather thorough perusal of related topics (using the index) shows not a single word related to this behaviour. No wonder I had no idea it would occur.

Thank you,
Robert Templeton