| Date: | August 20, 2007 / year-entry #306 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070820-01/?p=25503 |
| Comments: | 33 |
| Summary: | When you use Explorer to copy a folder, and the folder already exists at the destination, Explorer merges the contents of the folder being copied with the folder that is already there. Why was this behavior chosen instead of replacing the existing folder? My colleague Bob Day explains.¹ Nitpicker's Corner ¹Although this statement is written... |
When you use Explorer to copy a folder, and the folder already exists at the destination, Explorer merges the contents of the folder being copied with the folder that is already there. Why was this behavior chosen instead of replacing the existing folder? My colleague Bob Day explains.¹ Nitpicker's Corner ¹Although this statement is written as if it were a fact, the claim that Bob's remarks qualify as an "explanation" is actually my interpretation of his remarks and does not constitute an official position of Microsoft Corporation. |
Comments (33)
Comments are closed. |
As a switcher to the Mac I’ve been bitten by this. I prefer the Windows behaviour even though it isn’t really a replace operation.
But as a number of commenters on that article point out, the Apple behaviour actually does what it says it’s going to do.
If you’re going to merge the folders, you should be asking the user if they want to merge folders, not asking them if they want to replace them. I guess the real question to ask is:
"When you copy a folder, why does Windows ask you if you want to replace one folder with another when it’s actually going to merge them?"
Huh? That’s only natural when copying files, or moving from another drive/partition, since you can’t copy a directory (it’s not a supported filesystem operation), so you have to recursively copy its contents.
Now the interesting history is moving a folder within the same drive/partition to another place where there’s already one with the same name, because moving folders is a basic filesystem primitive.
However, you soon realize that you can’t overwrite non-empty folders, therefore your only options are recursively delete the previous one or move the contents then delete the empty parent source (what Explorer does).
Moral of the story: you have to try real hard to implement this in a way that causes dataloss.
"When you copy a folder, why does Windows ask you if you want to replace one folder with another when it’s actually going to merge them?"
Law of leaky abstractions?
For the most part, the copy operation is going to be working on files. So whenever a copy operation is about to happen on an object that exists, they ask you. Except that folders do the copy a bit differently.
The dialog in Vista is titled "Confirm Folder Replace" but the body of the dialog does make it clear that files of the same names may be replaced when you merge the folders.
It actually says the word "merge" and the body of the dialog is quite clear, IMO. It might be good for the title to be changed from "Replace" to "Merge," though.
OK, having read further down through the comments of the original article (and not having a Windows PC to test this on myself) I’ve finally discovered that Windows doesn’t actually ask you to replace the destination folder, it asks you if you want to replace the files in the destination folder.
So, although Windows and MacOS do different things, they both ask you different, but equally relevant and correct, questions. I guess that changes the real question to:
"Why did the author of the original article (implicitly) claim that MacOS and Windows ask the same question, when they clearly don’t?"
Today’s Nitpicker’s Corner is really brilliant!
> Today’s Nitpicker’s Corner is really brilliant!
I’m confused as to why it assumes only one nitpicker will read it.
Does anybody know what happens when you’re moving a large folder tree and there is a failure (e.g. network link goes down)?
I would expect that the Windows file operation would essentially start where it left off if it deletes the files during the move, or require you to hold down ‘N’ if it deletes the files after the move.
I would expect that the MacOS file operation would delete all previously moved files and leave you with only what was moved after the restart if it deletes the files during the move, or just start over again from scratch if it deletes the files after the move. In either case, it seems like it would be impossible to move large folders over an unreliable network.
Gabe:
Within a filesystem, a move is atomic (or hopefully, it’s the intent that counts).
Across filesystems or network, the current Windows implementation moves each component serially: it basically amounts to a copy immediately followed by a delete for each file, so to speak.
So if it’s interrupted, there won’t be a file in both places at once, unless the destination had a fatal failure or powerloss in which case the partial file will remain (usually upon failure the partial file is killed).
Oh and "no to all" is shift+click on "no", as Raymond pointed out a while ago. Great UI design, isn’t it?
"Why did the author of the original article (implicitly) claim that MacOS and Windows ask the same question, when they clearly don’t?"
Don’t fight the user experience, learn from it. This particular user said (paraphrased) "When I copy a folder on a Mac or PC, I get a dialog box. When I click ‘Yes’ on Windows, it does what I want. When I click ‘Yes’ on my Mac, it doesn’t."
This is an old lesson if you’ve ever done any UI work: Users don’t read dialog boxes.
Argue all you want about how the dialog box says clearly what it’s going to do and blah blah blah, but if you do that, you’re just fighting the inevitable. Users aren’t going to read your dialog boxes.
Brilliant! :laugh:
//Disclaimer: Although this comment is written as if it were The Truth, the assertion that Raymond’s nit-picking is brilliant is actually my personal opinion and does not necessarily reflect the reality of the situation.//
When replacing a folder, just first rename it to a new name, copy the folder, and delete the previous folder. Sure if the operation fails you are left with a half-arsed folder, but at least you won’t lose any files.
I think it’s time to change your blog tagline to "This blog does not constitute an official position of Microsoft Corporation"
I don’t know, what is in real life, but I think it should be default button to ‘No’ at least for Mac (because operation is dangerous).
And I think it could be ‘Yes’ for Win (because operation isn’t dangerous, and for already exist files it re-asks, if I want to replace exactly this file)
I don’t remember what behavior is in Win, and have used Mac about 10 years ago.
I think Raymond should permanently revoke the posting rights of nitpickers. Then we can get back to the real content instead of the legalese.
I think the default behaviour should be that users use their brains first and try to find out how this critical function works beforehand in the OS they currently (have to) use.
Stupid idea, I know. On the other hand … one could use the same program everywhere. Does Norton Commander run in dosemu under Mac too? I just hope dosemu emulates the copying-behaviour properly ;)
Back to punchcard-merging and deleting!
OK, Microsoft got this right. Yay! Now let’s get those smart people working on Windows networking.
Re nitpicker’s vs. nitpickers’: either is probably fine; although I’d probably lean to the plural version. The pitcher’s mound is not a good enough analogy. It is used by THE pitcher, never more than one at a time. All other pitchers are merely potential and/or former pitchers. Conversely, nitpicking can be performed simultaneously by multiple nitpickers. Which seems to be here amply demonstrated. There are good arguments for the singular case, but this is getting ridiculous.
btw, programmers are obviously trained to look for and catch little faults (i.e. nitpick). You can never trust the compiler to get them all.
p.s. Nitpicking used to be somewhat off-topic; thanks to the corner, it never will be.
I’ve read that a couple of times now, but I can never remember it when I actually need it. Gah.
I deny ever being smart enough to come up with those comments.
I do however confirm that I spelunked into the old Win3.1 source to find out what it did. I love code-archeology.
Still it makes a good story…
Oh, and after reading a bunch of those Mac-ist comments about Windows not knowing what "replace" means. Very funny to see how many of them complained. Check out how the actual text refers to replacing files, not folders.
Repeated for your amusement:
This folder already contains a folder named ‘100PENTX’.
If the files in the existing folder have the same name as files in the folder you are moving or copying, they will be replaced. Do you still want to move or copy the file?
[Yes] [Yes to All] [No] [Cancel]
Why it says "move or copy the FILE?" at the end is likely a bug. I wonder if it was fixed in Vista (where I went and fixed a bunch of these weird "file" vs "folder" messages).
@Miral:
I’ve read that (shift-click-no means no to all) a couple of times now, but I can never remember it when I actually need it. Gah.
==
I always remember it by thinking that I’m yelling at the computer. Shift-no means NO, goddammit!
> You know you’re in trouble when people nitpick the name of Nitpicker’s Corner
<grin>
> I guess I will have to link to this page every time
I’m sorry, but I’m not convinced. For one thing I’ve never seen it written as Lover’s Lane, and a quick Google search seems to confirm it is more commonly written Lovers’ Lane (640000 hits to 160000), which makes sense since Lover’s Lane suggests there is only one person there in which case it should be named more accurately.
@J
This particular user said (paraphrased) "When I click ‘Yes’ on my Mac…"
This is an old lesson if you’ve ever done any UI work: Users don’t read dialog boxes’
They don’t even read the buttons. The Mac hardly ever has dialog buttons labelled ‘Yes’ and ‘No’. In this case they are ‘Replace’ and ‘Stop’.
@Bob Day
‘Check out how the actual text refers to replacing files, not folders.’
I think the problem here is that you have to read the text, and then realise that the effect of replacing same named files is to merge the folders. It’s a nice test of reading comprehension and basic filesystem knowledge, but wouldn’t it be better to openly state what is going to happen rather than make the user infer it? ie ‘Do you want to merge folders? [Yes] [Abort] [Cancel] [Retry]’
Bob > You can’t really blame MacOS users for not magically knowing what the Windows dialog actually asked. After all, they’re not using Windows. The article poster did imply that the questions asked in both cases were the same. Given the poor quality of the complaint, the MacOS users responses are pretty understandable.
JamesW > I think the solution presented by some of the commenters to the other post is better:
"A folder with that name already exists. What do you want to do?
[Merge] [Replace] [Cancel]"
Put verbs describing the actions on the relevant button. People may not read the text of the dialog, but they’ll probably at least read the text of the buttons they have to choose between.
@Karellen
That’s an important "probably" right there. A sizable minority don’t read the buttons, either. IIRC, the trial version of WinZip put up the buttons on the nag dialog in a random order.
@Karellen
I know you should put sensible verbs on the buttons. That’s what the Mac does after all. I was having a dig at Windows dialog button conventions with my buttons. And you will be lucky if they read the buttons. Plenty of users will just hit the default as quickly as possible to get rid of the annoying dialog. Then write a blog entry on how the nasty computer ate their files.
I want computers to be smarter, the existing guis are stupid. Why not scan the target folder and check if there’s any files that will be replaced/erased, and warn the user about which and how many.
And a single dialog response from the user is propably not safe to use if the target folder do change after he/she do the choice. Asking the user again could be a solution to that, although I hate when a lengthy copy operation strand on replacement of read-only or moving exe files. Those (4-5 different possible) questions should be asked in the initial dialog if they’re relevant.
I don’t see how labeling the buttons with an action is going to solve the problem of users not reading dialog boxes. Users know that when a dialog box pops up, there’s a confirmation action and a cancel action. If they want the operation to work, they’ll hit the confirmation button without really reading it.
In this particular case, the user thought that copying a folder would merge. Even if there were two buttons labeled Replace and Stop, this user would have clicked Replace because he anticipated merging and just wanted to press the confirmation button to finish the operation. Sure, it’s the user’s fault, but arguing that detail is rather pointless.
[Merge] [Replace] [Stop] or whatever seems like an OK improvement, because the presence of two confirmation buttons might cause people to stop and think. But I wouldn’t count on it.
I’d go for:
"The destination already contains a folder with the same name
[Rename] [Cancel]"
and just come up with a new name for the folder, just as when you copy files into the folder they already are in. No chance of data loss, and if you actually want to merge the contents, just open both folders and copy/move the contents manually.
This is the worse proposed solution yet, for a number of reasons.
So if you have two folders marked "X" in real life, you clainm that you can’t put both of them into the filing cabinet?
Last time I tried that (in real life) it was possible:
To take just the contents from one of them and put all of it into a single "X" folder
Whatever you chosen from the aboe operations, it never resulted in losing the contents of one of the "X" folders you had.
So yes, Mac way is clearly broken, PC way is ok, and both could be better if they allowed duplicate names and used some other unique id to differentiate them internally.
Now, where should I apply for a user interface expert job?