From: Tom von Alten (tom_vonalten@boi.hp.com)
Date: Thu Jul 29 1999 - 12:10:44 CDT
Welcome back, Daniel!
Regarding the renaming of attachments, it does seem that hypermail v2a23 is
doing the renaming here.
I still haven't captured a message such that I can examine it before the
fact, but I have three views:
1) hypermail v2a23
2) hypermail v1.02+ (local)
3) Outlook98
The latter two say the attachments had names ending in .jpg and .pdf (the
two aberrant examples I've seen). The first says they were ".jpg_" and
".pdf_".
Daniel says:
> Hypermail saves the file with the name it got supplied. If
> the file name had a ".jpg_" extension it will be used.
V2a23 is most certainly prepending "att-" to the attachment name. And
parse.c defines "REPLACEMENT_CHAR" as '_', "to replace invalid characters
in supplied attachment filenames." Seems like an EOL mishandling, as Paul
Haldane suggested earlier.
But his proposed fix:
RCS file: /cvs/hypermail/hypermail/src/parse.c,v
retrieving revision 1.20
diff -r1.20 parse.c
1222c1222
< sscanf(fname, "%128[^\"]", attachname);
---
> sscanf(fname, "%128[^\"\n]", attachname);
did not do the trick. I looked at the "safe_filename" function in that
file, and the other sscanf statements... I notice one suggestive comment,
/* we could've done this with a %n in the sscanf, but we know all
sscanfs don't grok that */
Someone more conversant with parse.c and the parsemail() function where the
above sscanf is can probably track this down from these clues.
I hope!
_____________ Hewlett-Packard Computer Peripherals Bristol
Tom von Alten mailto:Tom_vonAlten@boi.hp.com
This posting is for informational purposes only.
It is not a statement of the Hewlett-Packard Co.