November 29th, 2013 • 4:05 pm
It used to be that one of Apple’s distinctive features when it comes to computing was its ability (and indeed its willingness) to sweat the details. Nowadays, more often than not, its distinctive features include a newly found ability to mess up the details.
In Mavericks’s Mail 7, as in previous versions of Mail, you can define a specific “Downloads” folder for saving e-mail attachments (under Preferences › General). The default folder for this is… your “Downloads” folder inside your user folder (which is also where all your Safari downloads go by default). But you can change it to any folder of your choice.
I have already discussed the changes introduced by Apple in Mail regarding the ability to save e-mail attachments in Mavericks. Sadly, these days, the fact that there are changes also means that there is a good chance that Apple has messed things up. And indeed it turns out to be the case here.
My problem today is with what happens when you try to save to Mail’s “Downloads” folder an attachment that bears the exact same file name as a file that already exists in that folder. If you choose the “ ” menu item in the contextual menu option when right-clicking on an attachment, since this menu item is for a command that does not require user interaction (there is no ellipsis at the end of it), when Mail finds an existing file with the same name as the attachment you are trying to save in the “Downloads” folder, it simply saves the new attachment with the same name in the folder with “-1” added to its name. (If there is already a “-1” at the end of the file name, it uses “-2”. And so on.)
So far, no complaints. This is the behaviour that I would expect.
The problem is with what happens if, instead of using the “Downloads” folder (which already contains a file with the same name) as the destination, when you click on the “Save” button in the dialog box, OS X correctly displays an alert warning you that there already is a file with the same name, and asking you if you want to replace it:” menu item in the contextual menu option, you use the “ ” menu item. This command, unlike the other one, requires user interaction. You have to choose the destination for saving the file. If you choose your “
The problem is with what happens if you click on “Replace” here. Instead of actually replacing the existing file with the new file, OS X… saves the new attachment with the same name in the folder with “-1” added to its name. In other words, it completely ignores your request to replace the existing file and does the same thing as the “ ” menu item does! Ironically, if you opt to save your attachments manually in a folder other than Mail’s “Downloads” folder, the problem does not occur. OS X correctly replaces the file. The problem is only with files saved in the default “Downloads” folder.
Like I said, it’s a detail, but it’s not an insignificant one. If you don’t pay attention and don’t notice this behaviour, you might end up having and using the wrong version of a file. You might think that your existing file with the name has been replaced, but it has not and is still the “old” file.
This is very unfortunate, and in my eyes, yet another sign that such details are increasingly escaping the attention of Apple’s developers. Such a flaw means that you essentially can no longer trust Apple to handle your files reliably without your supervision. Sadly, I am not surprised. When you see that the very notion of a file is being slowly deprecated in a computing environment such as iOS, you do wonder whether Apple can still be counted on to provide a proper “conventional” computing environment, where people create files, share them, store them, handle multiple versions of them, and so on.
iOS might be a fine operating system, but its level of complexity, as far as I am concerned, is a degree of magnitude lower than the level of complexity of OS X. If the developers that Apple has working on OS X these days cannot handle this higher level of complexity, we are in big trouble.