RE: octet-stream attachment

From: Tom von Alten <tom_vonalten_at_boi.hp.com_at_hypermail-project.org>
Date: Thu, 29 Jul 1999 11:10:44 -0600
Message-ID: <001001bed9e5$4b9e0d20$c9d1020f_at_alien-nt.boi.hp.com>

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_at_boi.hp.com

          This posting is for informational purposes only.
          It is not a statement of the Hewlett-Packard Co.

Received on Thu 29 Jul 1999 07:12:03 PM GMT