Finder File/Folder Overwrite Bug

• Create a new folder named "test"
• Elsewhere, create a file named "test"
• Drag file "test" over into folder "test"'s container.
• Finder X will warn "A newer item named "test" already exists in this location. Do you want to replace it with the older one you are moving?" with [Stop] [Replace] buttons.

Finder 9 correctly would not allow the action at all. That is, it would put up a "stop" alert with one unconditional button: [OK].

I accidentally deleted a folder filled with configuration files due to this bug, that couldn't occur under Mac OS 9. The folder was called "EOGenerator", and I was attempting to put the binary, "eogenerator", next to its configuration folder. I became momentarily confused at the warning dialog, but reacted just in time to realize the mistake I had made. Fortunately, I have backups...

Filed under RADAR #3184636.

Update: Bill Bumgarner asks "Why is this a bug?"

The flippant answer is that "it's not how Finder 9 did things". I'm an unabashed fan of the old Finder, largely due to its spatial interface. But I'm fully willing to admit Finder 9 wasn't perfect, and can be improved upon. Indeed, I think Finder X adds features that Finder 9 should have had long ago (toolbars for one).

No, my real answer is more subtle. A thought experiment: why did Finder 9 do it this way?. It's certainly not symmetrical -- Finder 9 allows you to replace files with files and folders with folders. This behavior doesn't save any code -- recursive folder deletion already needs to be present for the folder/folder replace scenario.

In fact, this behavior had to be explicitly added. Code has to compare the original object's ioFlAttrib flags against the replacement's. Adding to the complexity is that ioFlAttrib is a bitfield, which means an extra masking hoop has to be jumped through. Finally, add to the load the localization of two stop-alert strings ("You cannot replace the document "eogenerator", because a file cannot be replaced by a folder" and "You cannot replace the folder "EOGenerator", because a folder cannot be replaced by a file") and increased quality assurance burden.

With that background, we can rephrase the original question: Why did Apple go out of their way to make Finder 9 work this way? I can think of two possible reasons:

1. Finder 9's engineers are idiots.
2. Apple has human interface test results showing folks will eventually "accidently" delete files without this feature.

I prefer the latter explanation.

Erik also thinks this is not a bug. "It's not as if you're not warned.". Sorry Erik, but users don't read. Or, if they're anything like me, even if they do read, they're already five steps ahead of the machine and are already thinking of the next task while muscle memory autoconfirms every resulting "are you sure you want to do this?" type of roadblock.

Anyway, under Finder 9's model, it's okay if the user doesn't read the warning. The only available action -- [OK] -- simply dismisses the informational dialog. No data can be lost.

I'm worried I'm perhaps betraying my Human Interface Nazi heritage here, sounding too reasonable. Let me take it up a notch. I think replacing a folder with a folder and a file with a file -- allowed in Finder 9 -- shouldn't be allowed as well. Like typing replaces selection, its a very dangerous convenience. I believe the user should be forced to explicitly trash the original and put the replacement in the original's previous location.

I believe the only way such "dangerous conveniences" can be justified is if a persistent undo stack is always available. Finder X actually has much better undo support than Finder 9, but of course it doesn't work when you've replaced or deleted a file/folder -- when you need it most.

Update #2: Olof Hellman backs me up here.

Update #3: Erik follows up.

John Gruber weighs in. Quick responses:

• Sparkling? I choose to take that as a compliment. (grin)
• I concur "bug" isn't the right word. For Finder X, it's really a "feature request".
• You're probably right. Not quoting my Human Interface Nazi claim adds credibility. (grin)
• I'm cool with the "trash instead of overwrite" idea, and recognized the alias issue. I think your solution of making the Alias Manager even smarter would work. Another solution is to throw metadata at the problem and tag the trashed original with an alias to its replacement.
• I also believe that modern machines are saddled with designs whose tradeoffs are grounded in the processor and storage economics of the 1970s and 1980s. It's taking a long while, but more and more we're noticing these constraints no longer apply to us, and what we can do about them.

Oh, since Gruber doesn't mention it specifically, his article contains numerous references to Eric Shapiro's The Grouch, a system extension which had Oscar the Grouch popup and sing from the Macintosh trash can whenever emptied. I just checked, and "The Grouch-Application" still runs fine under Classic on Mac OS X.

Update #4: Michael Tsai agrees with Bill, with followup.

Update #5: Rainer Brockerhoff comments. I find it amusing Rainer says he agrees with Bill and Michael, but says he wants nondestructive behavior. Destructive behavior is why I called this a "bug" in the first place! Oh, and thanks for the welcome to the weblog world, Rainer!

Thursday, February 27, 2003
12:00 AM