Mac OS X’s Finder: Dumb Trash alert

Posted by Pierre Igot in: Macintosh
May 23rd, 2007 • 9:23 am

WARNING: The concentration of stupidity in this particular blog item might be hazardous to your UI health.

In the gallery of stupid Finder behaviours, this surely must be in the Top 10 attractions, in no small part due to the ease with which the behaviour can be reproduced. Here you go:

  1. Take any Finder item in any Finder window. As an example, let’s say the item is called “item.mp3.”
  2. Use the “Duplicate” command (command-D) to create a copy of the item in the same location. The Finder will automatically call it “item Copy.mp3.”
  3. Select “item Copy.mp3” and press command-Delete to put it in the Trash.
  4. Select the same item.mp3 item again.
  5. Use the “Duplicate” command (command-D) once again to create a copy of the item in the same location. Again, the Finder will automatically call it “item Copy.mp3.”
  6. Select “item Copy.mp3” and press command-Delete to put it in the Trash.

And here’s what you get from your dear friend Mr. Finder:

Name already taken

I am sorry, but this is just idiotic. I am trashing the item. What do I care whether the Trash already contains an item with the same name? Does my paper basket complain if I throw two copies of the same junk mail in it? (The reason for this is obviously that, to a certain extent, the Trash is just like any other folder in Mac OS X: It cannot contain two items with the exact same name. But it is equally obvious that the user does not care one bit about this particular limitation of the Trash in Mac OS X.)

Note that the alert text is not even good enough to give you a clear idea of what the problem is: Nowhere does it mention that the problem in question is with the contents of the Trash. The name is “already taken,” but the alert doesn’t tell you where and by whom.

And the recommendation (“Please choose a different name”) is equally stupid. Not only is it outrageously absurd to ask the user to rename a file before putting it in the Trash, but it’s not even necessary! Once you click on “OK” in the alert box, you will see that the Finder has indeed moved the file whose name was already taken to the Trash just the same. So what’s the problem?

In fact, if you look inside the Trash, you will see that the Finder has renamed one of the two files with the same name by adding some random numeric suffix to its name. So all is well: The two items are in the Trash, and they don’t have the same name anymore.

In other words, the alert box is not only stupid, it’s useless. It’s not necessary to warn the user about anything, because the Finder takes care of the problem by itself. Which is a good thing considering that the only option the alert gives you is… “OK.”

Like I said, the amount of stupidity that Apple’s engineers have managed to cram into this particular behaviour is just staggering. In my view, the engineers responsible should be forced to type the phrase:

The name “File Name” with extension “.ext” is already taken. Please chose a different name.

a hundred times every morning until the problem is fixed. That is the least I would demand as punishment for this UI crime.


8 Responses to “Mac OS X’s Finder: Dumb Trash alert”

  1. genbo says:

    Though I not opposed to reasonable Finder bashing, I cannot reproduce this bug (on an up-to-date 10.4.9, system language German).

  2. Pierre Igot says:

    Interesting. I cannot reproduce it in another user environment set up for testing purposes either. But I can definitely reproduce it in my current user environment.

    I wonder what is triggering it. It’s definitely a Finder alert (it has the Finder icon). I guess I might have to do more testing… Thanks for the additional information.

  3. danridley says:

    This happens to me frequently when working on a remote ZFS drive mounted via SMB from a Solaris system. However, it doesn’t happen on local drives. (10.4.9, Intel.)

    What’s odd is that the network drive doesn’t actually move items to the Trash; it deletes them immediately. (Network Trash only works on AFP mounts, as far as I can tell.) However, I get this message if I try to delete two files with the same name with a single command, even if the files are in different subfolders. Very annoying for folders with lots of Windows thumbs.db files; I usually drop to a Terminal to deal with that.

    I’ve assumed that the slightly out-of-date version of Samba that’s on that server was to blame.

  4. Pierre Igot says:

    Well, there’s definitely no ZFS/SMB involved in my situation. It’s definitely affecting files located on local volumes, including the startup volume. It’s probably one of these rarer bugs that crop up from time to time due to a variety of factors. Determining the exact factors would probably be way too much work for users like us…

  5. ssp says:

    I can’t remember seeing this problem and I definitely trash files with the same name quite frequently. One of the files in question gets renamed by adding a timestamp or some such thing to its name.

    [standard HFS+ volumes are in use here]

    (Of course life is still miserable as the OS X Finder lacks a put away command to restore things from the Trash and I won’t even start commenting on the whole “with extension” nuisance…)

  6. sjk says:

    You reminded me of a Finder Duplicate bug that I reported to Apple two years ago:

    Duplicate (command-D) in Finder generates error -8058 when attempting to duplicate certain items. Example: mount a disk image, select its desktop icon, and duplicate it. Error. And the volume won’t unmount until Finder is relaunched. Reproducible on a generic Tiger system.

  7. faifaifai says:

    i encounter the same bug today, i am using Leopard 10.5.3.

    You have to keep the info dialog opened (cmd+option+i) in order to reproduce the bug, or u will just have normal trash behavior, in which there is no alert even if u trash files with the same name.

    where to report the bug to apple?

  8. Pierre Igot says:

    The place to report bugs would be Bug Reporter. A registration with the Apple Developer Connection (ADC) is required, but it’s free.

Leave a Reply

Comments are closed.