After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 67554 - Misinterpretation of some string as attachment
Misinterpretation of some string as attachment
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
0.11.0.92
Other Linux
: Normal minor
: 0.13.3
Assigned To: Charles Kerr
Charles Kerr
: 76358 91506 98832 (view as bug list)
Depends on: 80366
Blocks:
 
 
Reported: 2001-12-26 19:31 UTC by fastviper
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sample message demonstrating this bug (2.35 KB, text/plain)
2002-06-17 22:26 UTC, Christophe Lambin
Details

Description fastviper 2001-12-26 19:31:19 UTC
When I put line in post:
begin 666 something.txt

I see in PAN:
Attachment: text/plain - 8bit - lack of file name
Attachment: text/plain - 8bit - something.txt

(I've translated above from polish).

This is Outlook-like bug. Pan should not see attachment, when there's no
attachment.
Comment 1 Charles Kerr 2002-01-02 02:51:40 UTC
I've confirmed that this happens when there are blank lines above an
attachment.  Kind of an awkward wart; perhaps Pan could walk through
the mime parts and trim out those which are just whitespace.
Comment 2 Charles Kerr 2002-04-13 22:45:01 UTC
Fixed in 0.11.90
Comment 3 Christophe Lambin 2002-06-17 22:16:21 UTC
*** Bug 76358 has been marked as a duplicate of this bug. ***
Comment 4 Christophe Lambin 2002-06-17 22:24:56 UTC
Reopening, since we regressed on this in later 0.11.9x releases: lines
beginning with 'begin <number> <word>' are now displayed as corrupted
code.  I'll attach an example below.

The underlying reason for this regression is related to multi-part
binaries: if we're reading the first part and we detect no end marker,
we'd fall back to displaying the raw text. For yenc-encoded messages,
this filled up the text with a huge chunk of yenc noise.

By removing that check for an end marker, we fixed the multi-part
problem, but regressed on this bug.

Comment 5 Christophe Lambin 2002-06-17 22:26:03 UTC
Created attachment 9287 [details]
Sample message demonstrating this bug
Comment 6 Christophe Lambin 2002-06-17 22:27:01 UTC
Note: Christopher Ranschaert <haploc@gmx.net> pointed this out to us.
Comment 7 Charles Kerr 2002-07-24 00:08:32 UTC
Since 0.12.9x does show multiparts picture posts,
we can add this code back in... anyone care to
make a patch from 0.11.90 to 0.12.92? :)
Comment 8 Charles Kerr 2002-07-28 04:07:35 UTC
Prioritizing remaining 0.13.0 tasks
Comment 9 Charles Kerr 2002-09-17 04:33:13 UTC
*** Bug 91506 has been marked as a duplicate of this bug. ***
Comment 10 Christophe Lambin 2002-10-11 00:00:07 UTC
Bumped remaining bugs to 0.13.2.
Comment 11 Charles Kerr 2002-10-17 17:11:41 UTC
For some reason this is a popular bug to complain about
in some newsgroups, so I guess I'll get off my ass and
fix it for 0.13.2. :)
Comment 12 Christophe Lambin 2002-11-13 20:53:14 UTC
Bumped remaining bugs to 0.13.3.
Comment 13 Charles Kerr 2002-11-18 01:53:38 UTC
*** Bug 98832 has been marked as a duplicate of this bug. ***
Comment 14 Charles Kerr 2002-11-19 01:12:56 UTC
Having looked at this bug some more, I find it hard to believe that
something so stupid could be so complex.

In order to make uu decoding work in a happy world, anything after
the "begin" line that doesn't pass the uu line sniff test is thrown
into the bit bucket.  so we would really need to rewind back to the
beginning of that part and re-run it.  Pathological cases with
uu begin lines one after another would be troublesome too.

Yes I'll fix it, but grumblingly... :)
"Doctor, it hurts when I do this."
Comment 15 Charles Kerr 2002-12-03 22:58:13 UTC
fixed in cvs for the next release:
http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan/pan/base&command=DIFF_FRAMESET&file=util-mime.c&rev1=1.48&rev2=1.49&root=/cvs/gnome
http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=pan&command=DIFF_FRAMESET&file=ANNOUNCE.html&rev1=1.1&rev2=1.2&root=/cvs/gnome

I've gone with a lazy fix to just catch the last uu/yenc message in
the article.  If someone does something nutty like adding two uu
begin lines at the top of an article, Pan will probably still get
confused. :|