RTF attachment name
Bo...@emanon.net
I'm using Eudora 7.0.1 paid mode on an XP Pro system.
Every time I attach an RTF file to an email, the title of the file is
changed to whatever the subject line is plus a 1 or subsequent number.
Any suggestions how I correct this? I want it to carry the original
file name.
Many thanks.
Boxer
John H Meyers
> I'm not sure if this is a WORD problem or a Eudora problem.
Neither -- it's all actually as Nature intended (see below)
> I'm using Eudora 7.0.1 paid mode on an XP Pro system.
> Every time I attach an RTF file to an email, the title of the file is
> changed to whatever the subject line is plus a 1 or subsequent number.
I've sent an RTF file to myself three times; each attachment was
*sent* with the identical file name but different "Subject,"
as I've verified by looking on the POP server.
When *received* by Eudora, however, duplicate file names
necessarily have to be adjusted, as follows:
hello.rtf Subject: Here is hello.rtf
hello1.rtf Subject: Here is hello.rtf again
hello2.rtf Subject: Here is hello.rtf third time
> Any suggestions how I correct this?
It's actually normal and proper behavior.
> I want it to carry the original file name.
That's exactly what happens if possible, but the reason that numbers
are appended to *duplicate* file names when *received* (not when sent)
is that Windows can not store multiple files having the same name,
into the same folder, so Eudora automatically adjusts *received*
attachments to have unique names, thus preventing the overwriting
of other attachments received earlier -- even if an application
makes resolving file name collisions a manual process,
asking a user to either confirm overwriting or change the file name,
there is still no way that multiple separately emailed files
whose names happen to coincide can all be stored with the same name,
so you would have to either use different names yourself,
or else overwrite your older files that had the same name.
Email clients that don't extract attachments until you read the
message and request to decode the attachment can offer an additional
option, which is that you could store each subsequent attachment
into a different *folder*, but since Eudora extracts attachments
before the message even appears in your Inbox, and since it's
generally the case that one can not make one new folder per
attachment anyway, Eudora automates the process of selecting
non-conflicting names -- you can, however, *rename*
any attachment *after* receipt (or even move it to a new folder),
so you can still do whatever you want, in the final analysis.
If you replaced Windows with an operating system called VMS, however,
you *could* store multiple files with the same name -- but then these
would be called "hello.rtf;1" and "hello.rtf;2" and "hello.rtf;3"
(files having the "same name" but different "version numbers")
with "hello.rtf" referencing only the most *recent* version.
Finally, if you stored too many versions, then the oldest
versions would just silently ascend to heaven anyway,
and could no longer be retrieved.
Is this any better than just appending a "version number"
to the file name, and saving all that confusion?
(VMS was not my favorite operating system,
in case you couldn't guess :)
--
John H Meyers
by automatically appending numbers]
One way to guarantee the preservation of original file names
is to enclose attached files in an "archive" ("zip" being popular);
in this way, if duplicate-name *zip* archives are received,
the *zip* files will have numbers appended (before any "extension"),
but the names of the files *inside* the archive will be preserved.
The "unzip" program will then ask you to resolve any conflicts
at the time of file extraction, just like other email clients
which delay attachment extraction until you request it.
If you open attachments one at a time, and then discard them,
you will then never encounter any name conflicts,
but if you want to save attachments over time,
then sooner or later you will encounter the same issue,
just having deferred it until later.
--
John H Meyers
> I'm not sure if this is a WORD problem or a Eudora problem.
> Every time I attach an RTF file to an email,
> the title of the file is changed to whatever the subject line is...
Mmm.. Are you mailing using an embedded feature within MS Word?
If so, might be better to look for the file as already stored,
in Windows Explorer, see what its name is, drag that file
to a Eudora email message window during composing --
this attaches the file to the message,
using its name as already stored on disk,
and you can see that name in the "Attached" header line
(initial path components C:\...\...\ will not be transmitted;
only the final name component is sent in outgoing mail).
Any duplicate attachment name will still get numbers appended
upon *receipt*, if necessary to avoid overwriting an existing
attachment of the same name that was already stored
in the Eudora attachments folder.
--
Wyel
I do have "include text messages in body of message" checked, which is
what I think you meant.
I suppose I could change the subject line--probably should--since
sometimes I have had subject lines pertaining to something completely
different and also included an attachment. I.E., A subject line: Class
starts June 1 and an unrelated attachment, perhaps a map, recipe, or
something. The attachment will arrive as Class starts June 1/1 and
Class starts June 1/2, no matter what the name of the file I actually
attached is. I have even drilled down in the directory and selected the
exact file that way. I have copied the files to the "Attachment"
directory and tried that. Nothing changes. It sends whatever the
correct attachment, but titled whatever the subject line happens to be.
When I send myself a copy to check, it still arrives as Class starts
June 1/1...." etc.
Not very intuitive.
Thanks for the very good, detailed answer. At least I understand it
now. I think.
Boxer
John H Meyers
> I do have "include text messages in body of message" checked,
> which is what I think you meant.
Try the opposite :)
I *thought* that I'd tried it each way (there's a tool button
within the "compose" window to change it on the fly, per message),
but perhaps I failed to do it right :)
> I suppose I could change the subject line--probably should--since
> sometimes I have had subject lines pertaining to something completely
> different and also included an attachment. I.E., A subject line: Class
> starts June 1 and an unrelated attachment, perhaps a map, recipe, or
> something. The attachment will arrive as Class starts June 1/1 and
> Class starts June 1/2, no matter what the name of the file I actually
> attached is. I have even drilled down in the directory and selected the
> exact file that way. I have copied the files to the "Attachment"
> directory and tried that. Nothing changes. It sends whatever the
> correct attachment, but titled whatever the subject line happens to be.
> When I send myself a copy to check, it still arrives as "Class starts
> June 1/1...." etc.
Does the file path in the "Attached:" header end with
an ordinary file name that's *not* the subject line?
Have you tried pressing *down*
the "Text as attachment" composition toolbar button
(just to the right of "QP" in my windows) before sending,
or un-check the global option in
Tools > Options > Attachments
[ ] Put text attachments in body of message.
I was unable to get my atachments to change their names
to the subject line text, so I must be doing something wrong ;)
> Not very intuitive.
I've always avoided "text attachments in body of message,"
so my actual experience has a gap there.
The Eudora 7.1 PDF manual on page 33 explains the
"Text As Attachment" composition button as:
"If this button is on, plain text files are attached to messages,
not incorporated into the message as part of the message body."
And on page 312 it explains the
[ ] "Put text attachments in body of message"
check mark in the global "Attachment" options as
"If you select this option, Eudora puts any plain-text
attachment you send directly within the message body,
as if it were typed in manually."
The button's state being *opposite* to the check-mark in the
global option probably doesn't help here :)
At any rate, if I believe what the manual says,
it means I believe that including the text "in-line"
should not produce any "attached" file at all,
but should merely include the content of the file
as if copied and pasted into the message,
yet you say that you still get an attached file
(RTF files consist entirely of displayable and printable
"ascii" characters, but I don't know exactly what criterion
Eudora uses to decide whether a file is "just text,"
for purpose of this option, since you obviously didn't
get the text (full of expressions in "curly braces")
inserted in the middle of your email, right?
I would try *not* specifying that "in-line" option
(un-check the global option, make sure the button
in the composition window is "down" before sending),
if you didn't before, and see what happens then.
> Thanks for the very detailed answer.
I have to write long answers to better learn the stuff myself :)
Thanks for the opportunity, and best wishes.
--
nospam
"John H Meyers" <jhme...@nomail.invalid> wrote in message
news:op.tr8ha...@w2kjhm.ia.mum.edu...
I was was able to duplicate Boxer's problem with a .rtf file and with
the 'Put text messages in body of message' checked. Uncheck that feature
and the trouble goes away. A .txt message doesn't display the same error.
Didn't try any other extensions.
nospam
"John H Meyers" <jhme...@nomail.invalid> wrote in message
news:op.tr8ha...@w2kjhm.ia.mum.edu...
Not sure I have the original sender's name correct. Anyway, just for
drill I attached 2 .rtf files and only the name of the first seems to be
incorrect because of the aforementioned feature. The second .rtf had the
correct file name.
John H Meyers
> I was was able to duplicate Boxer's problem with a .rtf file
> and with the 'Put text messages in body of message' checked.
> Uncheck that feature and the trouble goes away.
> A .txt message doesn't display the same error.
> Didn't try any other extensions.
On Sun, 13 May 2007 07:00:31 -0500, nospam wrote again:
> Just for drill I attached 2 .rtf files
> and only the name of the first seems to be incorrect
> because of the aforementioned feature.
> The second .rtf had the correct file name.
I'm glad you were able to duplicate this!
(as well as uncover more of its interesting behavior)
Which Eudora version are you using?
With both 7.1.0.9 and 6.2.5.6, with "text in body" checked
(and verified by the corresponding "compose" button being "up"),
I've sent two RTF attachments (HelloA.rtf and HelloB.rtf)
in one message,
and they were both sent with their proper file names.
To try harder to confuse Eudora, I also took out the "rtf"
entry in my [Mappings] section of [d]eudora.ini -- this
caused Eudora (7.1.0.9) to change its mind from
describing the first attachment this way:
Content-Type: application/rtf; name="HelloA.rtf";
x-mac-type="42494E41"; x-mac-creator="4D535744"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="HelloA.rtf"
To this way:
Content-Type: application/octet-stream; name="HelloA.rtf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="HelloA.rtf"
But still, as can be seen above,
the file name is what it should be,
rather than being taken from:
Subject: Two RTF files attached
It's interesting that even though the file content
of a true RTF file is all ascii, Eudora doesn't really
include it in the message body, as the manual was suggesting,
but sent the files as attachments anyway -- just evidently
manifesting some very weird [and apparently rare] bug(?),
depending on other as yet unknown factors,
besides just selecting the "text in body" option(?).
To satisfy the curious, here's what my file "HelloA.rtf"
looks like in WritePad [in Arial font, size 10]:
HelloA
And here's what the same file looks like in Notepad:
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}}
\viewkind4\uc1\pard\f0\fs20 HelloA\par
\par
}
If you'd like to send me any RTF file (or pair) so that I can see
what it looks like in "original format" on the POP server
(which I'd be glad to post if you do),
you could append my real domain "miu.edu"
to the first part of my invalid posting email address.
Well, as the New York Times likes to say,
that's "All the news that's fit to print"
Or as my school newspaper used to say,
"All the news that fits, we print" :)
--
nospam
"John H Meyers" <jhme...@nomail.invalid> wrote in message
On Sun, 13 May 2007 06:17:29 -0500, nospam wrote:
> I was was able to duplicate Boxer's problem with a .rtf file
> and with the 'Put text messages in body of message' checked.
> Uncheck that feature and the trouble goes away.
> A .txt message doesn't display the same error.
> Didn't try any other extensions.
On Sun, 13 May 2007 07:00:31 -0500, nospam wrote again:
> Just for drill I attached 2 .rtf files
> and only the name of the first seems to be incorrect
> because of the aforementioned feature.
> The second .rtf had the correct file name.
I'm glad you were able to duplicate this!
(as well as uncover more of its interesting behavior)
Which Eudora version are you using?
Results seem to be the same with 7109 and 6256. Both sponsored in my case.
The misnaming with more than one .rtf seems to be alphabetically related.
I sent three .rtf's and the first two alphabetically were misnamed and the
third was correctly named. However, it all goes away with 'text in body'
unchecked.
With both 7.1.0.9 and 6.2.5.6, with "text in body" checked
(and verified by the corresponding "compose" button being "up"),
I've sent two RTF attachments (HelloA.rtf and HelloB.rtf)
in one message,
and they were both sent with their proper file names.
You lost me with "compose" button being "up".
John H Meyers
> Results seem to be the same with [Eudora versions] 7109 and 6256.
Hmm.. could it be OS related? (Win2K here)
The files I attached were on my desktop
(full path names contain spaces,
though the "simple" file names did not).
> The misnaming with more than one .rtf
> seems to be alphabetically related.
> I sent three .rtf's and the first two alphabetically
> were misnamed and the third was correctly named.
"Curiouser and Curiouser" [Lewis Carroll] :)
http://www.bartleby.com/66/15/10615.html
ftp://ibiblio.org/pub/docs/books/gutenberg/etext97/alice30h.htm
http://msdn2.microsoft.com/en-us/library/bb250484.aspx
> However, it all goes away with 'text in body' unchecked.
Thank goodness!
> You lost me with "compose" button being "up"
There's normally a "Text as Attachment" tool button
in each message composition window,
enabling per-message choice of which way to send
(the button's initial state is set by the global option).
Anyone who can reproduce the bug is invited to send me a copy
(fake your return address if you like, only content matters)
Replace the domain of my invalid posting address with "miu.edu"
Thanks.
--
nospam
"John H Meyers" <jhme...@nomail.invalid> wrote in message
> On Sun, 13 May 2007 09:38:11 -0500, nospam kindly wrote:
>
>> Results seem to be the same with [Eudora versions] 7109 and 6256.
>
> Hmm.. could it be OS related? (Win2K here)
XP 5.1.2600
>
> The files I attached were on my desktop
> (full path names contain spaces,
> though the "simple" file names did not).
>
>> The misnaming with more than one .rtf
>> seems to be alphabetically related.
>> I sent three .rtf's and the first two alphabetically
>> were misnamed and the third was correctly named.
>
> "Curiouser and Curiouser" [Lewis Carroll] :)
> http://www.bartleby.com/66/15/10615.html
> ftp://ibiblio.org/pub/docs/books/gutenberg/etext97/alice30h.htm
> http://msdn2.microsoft.com/en-us/library/bb250484.aspx
>
>> However, it all goes away with 'text in body' unchecked.
>
> Thank goodness!
>
>> You lost me with "compose" button being "up"
>
> There's normally a "Text as Attachment" tool button
> in each message composition window,
> enabling per-message choice of which way to send
> (the button's initial state is set by the global option).
>
> Anyone who can reproduce the bug is invited to send me a copy
> (fake your return address if you like, only content matters)
>
> Replace the domain of my invalid posting address with "miu.edu"
>
> Thanks.
>
> --
I did send to a little different address which I had from an earlier
exchange. Still valid?
John H Meyers
> I did send...
Yes, messages have since arrived:
> Using 6256 with "body in message" checked with one attachment.
Message excerpt (from POP server):
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Content-Type: multipart/mixed;
boundary="=====================_18506500==_"
[...]
--=====================_18506500==_
Content-Type: application/rtf; charset="us-ascii"
Content-Disposition: attachment; filename="Eula.rtf"
{\rtf1\adeflang1025\ansi\ansicpg1252\...
--=====================_18506500==_--
Well, that has a proper file name
(and as a twist, is plain "ascii,"
rather than being "base64" encoded, as mine was)
It also doesn't specify the "Mac[intosh] types"
(which I certainly don't need, just noting differences).
> I bcc'ed that mail to you a few minutes back
> to one of my addresses and the file was properly named,
> but it fails when I send to me as the lone recipient.
Oh boy, I bet the real reason that Qualcomm made 7.1.0.9
the "final" release is that it's become too complex
for any human mind to debug :)
> How did yours appear?
As above (correct file name), which it had to be,
since the very same message body is sent to each recipient,
and this is the one you received correctly, with Bcc to me.
You can try sending to me as the lone recipient, if you like,
and I'll tell you what I get next time.
From all this, I think we can definitely conclude
that AMVAL (Attached Mileage Varies A Lot :)
--
nospam
"John H Meyers" <jhme...@nomail.invalid> wrote in message
> I did send...
--=====================_18506500==_--
> How did yours appear?
On the way..
Ajo Wissink
<jhme...@nomail.invalid> wrote:
>It's interesting that even though the file content
>of a true RTF file is all ascii, Eudora doesn't really
>include it in the message body, as the manual was suggesting,
>but sent the files as attachments anyway -- just evidently
>manifesting some very weird [and apparently rare] bug(?),
>depending on other as yet unknown factors,
>besides just selecting the "text in body" option(?).
I will do some testing and report the results.
In the meantime, I have always interpreted "put text attachments in
body of message" as just that what it says. Eudora will do that for
files in .txt format and not for files with another extension although
they may contain just pure text, such as .doc, .rtf, .pdf, etc.
--
Ajo Wissink
--
Posted via a free Usenet account from http://www.teranews.com
John H Meyers
> You can try sending to me as the lone recipient, if you like,
> and I'll tell you what I get next time.
On Sun, 13 May 2007 13:34:57 -0500, nospam wrote:
> On the way..
Well, I've finally caught up with viewing the POP server,
and here's what I received:
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 13 May 2007 13:29:58 -0500
Subject: .rtf
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="=====================_2430546==_"
--=====================_2430546==_
Content-Type: text/plain; charset="us-ascii"
Here is the file to you alone.. Will also send with 7109.
--=====================_2430546==_
Content-Type: application/rtf; charset="us-ascii"
Content-Disposition: attachment; filename="Eula.rtf"
{\rtf1\adeflang1025\ansi\ansicpg1252\uc1\adeff37\....
--=====================_2430546==_--
[End of message sent using Eudora Version 6.2.5.6]
The attachment above is properly named, so no problem,
but here comes the first example of a problem message:
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sun, 13 May 2007 13:32:14 -0500
Subject: .rtf
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="=====================_2453718==_"
--=====================_2453718==_
Content-Type: text/plain; charset="us-ascii"
Here it is with 7109.
--=====================_2453718==_
Content-Type: application/rtf; charset="us-ascii"
{\rtf1\adeflang1025\ansi\ansicpg1252\uc1\adeff37\...
--=====================_2453718==_--
[End of message sent using Eudora Version 7.1.0.9]
AHA! -- NO FILE NAME SPECIFIED for the above attachment!
(actually, no "Content-Disposition:" header at all)
So, Gmail (where this item is currently parked)
calls the attached file "noname" -- but Eudora,
apparently looking for a more creative way
to hint at content, for the recipient's sake,
uses the message "Subject:" as the file name
(my 7.1.0.9 called it "rtf" -- so did it even intelligently
delete the leading "." character from the subject?)
Okay, my self-assigned role was to report what
the "raw" message actually contained; I'll leave it
to others to try to determine under what circumstances
Eudora *sends* such attachments without "Content-Disposition:"
(and hence no file name), which thus far has been vaguely
described as "alphabetically related" -- and then only
if "text in body" option is on (or finally,
if "text as attachment" button in compose window is off,
the "option" having served only to initially set the button state).
Note that there are actually two independent issues
in the complete chain of events:
o At moment of sending by Eudora,
omission of a file name for attachment,
when requested to be included in body
but attached instead, because not named "xxx.txt"
(according to Ajo), and then only sometimes,
according to file type and/or file name.
o At later time of *receiving* by Eudora, use of "Subject:"
as attachment name when no file name is *received*
(other email clients will each "do their own thing"
about how to handle unnamed attachments, since internet
standards cover only what's done in public, not within
the privacy of the personal computer in your bedroom :)
--