Mac OS X’s Mail: Don’t modify a file after attaching it to an e-mail message
Posted by Pierre Igot in: MailMay 3rd, 2005 • 6:52 am
I have just realized something about Mac OS X’s Mail that I wasn’t fully aware of and that has probably caused me to send the wrong version of a number of attachments over the years to my correspondents.
I used to be a Eudora user. In Eudora, when you composed a new e-mail message and then attached a file to the message, Eudora only established a link between the e-mail message and the attached file. As long as you didn’t send the e-mail message in question, the “attachment” was just that: a link to the file. This meant that, even after you had started composing the e-mail message and attached the file to it, you could still return to the file and continue editing it and saving it in its parent application. When you were finally done with editing the file and had finally saved it one more time, you would return to the message window in Eudora and click on the “Send” button to send the message. This would send the e-mail message with an attachment consisting of the very latest version of the file that you had just saved. In other words, Eudora would only convert the link into a full-blown attachment (i.e. encoded stuff actually included in the body of your e-mail message) when you clicked on the “Send” button.
And I have just realized that this is not the case in Mail. In Mail, the encoding of the attached file takes place immediately when you attach the file. In other words, when you attach a file to an e-mail message in Mail, Mail actually copies the file in encoded form into the body of the e-mail message. If, after that, you leave your message window open and return to your original file in its parent application and continue editing and saving it, this will not affect the version of the file that’s included in the e-mail message that you’ve left open in Mail.
Argh! Because of the way Eudora used to work (I don’t know if it still works this way), I have been doing this in Mail (attaching a file to an e-mail and then further editing it in its parent application) thinking that the attachment would be automatically updated to reflect the further changes! This is rather problematic, because it means that, over the past few years, I have been sending files to people that were not actually the final version that I had meant to send. And we are talking about work here! Nearly all the translations that I do as part of my work are delivered to the client via e-mail, and I am quite sure that, out of this old habit from my Eudora days, I have made this mistake a number of times over the years.
Of course, since the further changes made to the files are usually minor textual adjustments, my clients have never noticed the problem. This means that they have probably received files from me still containing some typos or mistakes that I did correct in my final version, but only after I had already attached the file to an e-mail message.
It’s not a huge disaster, but it’s still a bit embarrassing…
And when you think about it, it is a problem with the very concept of “attaching” files. There is nothing in the Mail interface that indicates that, when you attach a file, you are actually including a copy of the file into your e-mail message. There is nothing that indicates that there is a difference between that file and the original that you can continue to work on.
(The interface problems also affect the other part of the equation. When you receive attachments, if you treat them as files and try to launch them from within the e-mail message by double-clicking on them, it doesn’t always work. Sometimes you have to drag the file to the desktop first, which effectively creates a copy of the file on the desktop. It’s a concept that’s not always easy to explain to the end user who doesn’t understand why double-clicking on the file in the e-mail message doesn’t work and doesn’t understand exactly where the file that appears in the e-mail message’s body actually is on his hard drive.)