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
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
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
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
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).
- 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.
- 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
