Subscribe to
Posts
Comments
NSLog(); Header Image

Replace

It's funny to read the comments of the PC-ites on the meaning of the word "replace." So funny it prompted a Daring Fireball article.

I wasn't aware of the Windows way of doing things - "merging" instead of "replacing." To me, the Mac definition is far closer to the meaning of the word "replace."

Folders are containers, but they're single entities in and of themselves. "Replace foo with bar" works on the Mac regardless of whether foo and bar are folders or files. If Matt really wanted to "merge," he could have simply dragged the contents of the folder.

Having read the comments (a few - not all), it's clear to me that this is one of those things that's simply tough to understand from the other point of view. Windows has its (cough, wrong, ahem) way, and the Mac does it the right, errr, its way.

15 Responses to "Replace"

  1. The issue is not "wrong" verses "right", the real issues is why don't both systems have a "merge" option.

    I need and like both. I find myself wanting to do exactly what PhotoMatt was trying to do, and it works on the PC but fails on the Mac. Why not have a "Merge..." option as well? This all seems very simple until you start dealing with sub-folders, then it can really mess you up. You can't just drag the "contents" of the folder if that folder contains files and folders, which contain sub-folders, etc, etc.

  2. I think the whole thinking behind this is wrong. If you have a real life container with real life folders in it, and you plop in another real life folder with the same name, nothing at all will happen. That it's spatially inconsistent with what would happen with a file is a moot argument - a folder is fundamentally different from a file in real life as well as in the computer model. The only common ground is that they're both, at a very low level, entities, both in real life and in the file system.

    I was almost solely a Mac user for the first eight years of my life. I used Windows, of course, but when it came to anything involving files I used the Mac. I liked the way the "Classic" Finder worked (as do I now). When I went to Windows and started encountering stuff like this, the merging way just appeared to be the right way.

    I've never in my entire life ended up in a position where *replacing* rather than *merging* seems more coherent, logical and in fact *what I actually want*. Since I first read about that this is the way it's done (also at DF, a year or two ago) I've actually been trying to make up outlandish scenarios once in a while, seeing if I'd ever arrive in a situation where I'd want to replace rather than merge, but I haven't found anything. Not a one.

    What it all boils down to, I guess, is that I've used the 'merging' solution to my advantage several times even today, but not the 'copying' solution *ever*.

    I think that this is one of the few ways in which the spatial system can afford to "bend" a little for the purpose of the intended usage. Even conceding to it being strictly logically correct - which I doubt - it's wholly counter-intuitive at its core.

  3. Anybody who doesn't like a behavior of the OS can and should report it as a bug/feature request to Apple. ADC members can log in at http://connect.apple.com/ and anybody can report a bug to Apple without using an account at http://developer.apple.com/bugreporter/bugrptform.html.

    I just did, regarding this subject. (I don't mind the merging issue, though they ought to clarify things ... but I do mind that replaced items aren't put in the trash.)

  4. I disagree, Dan, that the wording needs clarified. It makes perfect sense to me.

    I wouldn't be bothered if things were moved to the trash, though in most instances it'd create an extra step for me. I never replace anything accidentally, and in the instances in which a need later arises, I simply revert to my daily backup. Daily backups, I also realize, are not the norm.

  5. the "Do you want to replace it? Cancel/Replace" dialog should instead be something like "The folder you are moving has the same name as an existing folder. You may either replace the old folder with the new one, removing any old files, or you may merge the contents of the two folders. Cancel/Replace/Merge"

    I usually want to replace the folder (for example, if I'm replacing an old version of an app with a new one) but occasionally i want to merge two folders (the most common example being the movement of collections of photos or other media)

  6. There's absolutely no reason to implement "merge." Spend more than a day or two doing basic Mac tech support and you'll come to understand the level at which most Mac users operate. "Merge," particularly with subfolders, is well beyond their typical capabilities.

  7. I usually want to replace the folder (for example, if I'm replacing an old version of an app with a new one) but occasionally i want to merge two folders (the most common example being the movement of collections of photos or other media)

    Well, keep in mind that merging folders will still replace an old app with a new one. All the old files that are the same are overwritten. Also keep in mind that if you really want to trash one folder and put another in it's place you can still do that, by literally doing just that.

    There's absolutely no reason to implement "merge."

    I both respectivefully and emphatically disagree. I learned about merging when I first started to get into modding games, and the ability to copy an entire folder hierarchy of files into a new location without losing all the other files in there was profoundly invaluable. Since then I've used merge frequently when I've want to move files around from one location to another. It's great for me because I keep a folder called "Papers" at work and the same folder at home. When I'm at work I download my papers to read, put them on my thumbdrive, then merge them with the papers on my home computer. It's incredibly helpful.

    The main problem with how the Mac is doing replace is that it allows you to take a folder with only one item in it and completely overwrite a folder with 100 items in it. That, to me, doesn't make any practical sense. Like Jesper, I can't even comprehend a real world situation where you'd want to do something like that.

    Ultimately I think delete should mean delete, and nothing else should have the same effect. That's the safest, and most consistent, way of handling files.

  8. Nima, I'm glad you disagree. Unfortunately, just because you use merge doesn't mean that it makes sense or would benefit 99% of the users out there. Particularly when it's called "replace." It makes sense because, well, the action matches the definition of the word is "replace." It does not match the action of the word "merge."

  9. Nima, I'm glad you disagree. Unfortunately, just because you use merge doesn't mean that it makes sense or would benefit 99% of the users out there. Particularly when it's called "replace." It makes sense because, well, the action matches the definition of the word is "replace." It does not match the action of the word "merge."

    So you are saying even though it's more useful, less harmful, and practically helpful, this implementation is "bad" because Microsoft uses the word "replace" in the title of the dialog instead of "merge"?

    Right. Thanks. But you know what, if it can protect hundreds of my files from accidentally getting deleted and can be used in a variety of useful ways for me, I'll take it.

    And honestly, I've never met a single Windows user who's said to me, "You know, I really wish copying a folder to another location would just wipe out the folder that's already there, regardless of what it contains." Yeah, I've never heard that one.

  10. Nima, it's useless because "merge" is ambiguous. What happens with subfolders? You want to do complex merges, fine: it's a complex task that people who should undertake it already know how to solve. But it pretty much screws with the heads of 95% of the computer using public.

  11. Nima, it's useless because "merge" is ambiguous. What happens with subfolders?

    The dialog doesn't use the term "merge", it's us who do. What the dialog does do is clearly say that the files in the folder of the same file name will be replaced. From that, I believe it's very clear what's going to happen with subfolders.

    You want to do complex merges, fine: it's a complex task that people who should undertake it already know how to solve. But it pretty much screws with the heads of 95% of the computer using public.

    Well, since 95% of the computer using public uses Windows I don't think so, but just for arguments sake lets say you're right and 95% of people have difficulty conceptualizing what Windows is doing. Even considering that, there is no negative side effect. That is, moving folders around in Windows will not result in the kind of data loss that Matt experienced. Unfortunately, the same isn't true the other way. If you aren't 100% sure of the contents of the folder you're moving on a Mac, you can end up losing an entire folder (plus it's subfolders) worth of information.

    That's the real kicker. OS X lost Matt's data, but that would not have happened on Windows. It's really as simple as that. Apple is using an antiquated folder handling system, which I believe is ridiculous when you consider how much more sophisticated file handling on OS X is in general. It needs to be changed, and I think stealing from Windows would not be a bad idea in this case.

  12. Nima, if I have 100 files in a folder and I want to cleanly replace them with 100 other files - some differently named, some the same - and Windows "merges" the files when it tells me it will "replace" them, and I'm later forced to go through and try to figure out which ones were in fact the ones I intended to replace, then that's a problem.

    I disagree with you that it "needs" to be changed. Windows does - either in its wording or its application - but the Mac is very clear in its wording and function in a way that makes sense to a whole heckuva lot of people. Particularly for Mac OS X, given that many applications are bundles (folders).

  13. Eric: "Windows does - either in its wording or its application"

    I agree with that.

    Now, let's pretend that we're changing the Finder so that it offers the option to either "replace" or "merge" (wherein "replace" means replace, and "merge" works like the windows implementation). How would you word the dialog and place the buttons? This is what comes to my mind:

    "I haven't thought about wording yet"

    Replace | Stop | Merge

    Replace gets placed on the left becaue it is the more destructive of the two operations. Thus, merge becomes the default and is placed on the right.

    My example would be a change from the current default behavior. Would that be unacceptable?

  14. I'm restoring some files from a backup. I want to just drag and drop one folder onto another and have their contents and entire folder structure to be merged.

    Unfortunately, Finder insists on replacing the existing folders instead of merging the contents.

    How do I merge the contents of these folders? Basically, I'm looking to perform what Windows considers the default behavior when you drag and drop one file onto another.

    I know there are a number of people who've posted to this thread who insist my needs aren't important because Mac os X is already doing it the "right" way. I'm impressed that those Mac fanboys are flexible enough to get their heads so far up their rears they can taste their own hair gel.

    I have a need. Windows meets that need, Mac is failing miserably. All I've found from hunting this up online is advice to use a command line utility that gives me a "Directory not empty" error, and pedantic arrogant babbling from idiots insisting the feature I need isn't valid.

  15. Matthew, you're missing the point that once you merge - even accidentally - "unmerging" is very difficult. Your situation seems quite contrived, and your wisecracks about hair gel and flexibility are in poor taste.


Trackback URI | Comments RSS

Leave a Reply

Please abide by the comment policy. Valid HTML includes: <blockquote><p>, <em>, <strong>, <ul>, <ol>, and <a href>. Please use the "Quote Me" functionality to quote comments.