Re: archive not showing all attachements

On Sat, Mar 26, 2022 at 8:11 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2022-03-26 18:41:39 +0100, Magnus Hagander wrote:
> > That said, it's not as simple as a upper/lowercase. get_content_type()
> > returns 'text/plain' in lowercase for both parts so it takes care of
> > that.
> >
> > The problem is that:
> > 1. It's not an attachment. That is:
> > Content-Disposition: inline; filename="0001-doc_wip-diff.txt"
> > explicitly says it's not an attachment.
>
> It's not actually that unreasonable for a doc patch ;)
>

Agreed. But it does explain why it's not shown *as an attachment*.

> > 2. We only show the first plaintext part of messages
> >
> > This is the actual problem. Our archives don't know how to merge
> > multiple plaintext parts when they are set to be viewed inline and not
> > as attachments.
> >
> > That said, I notice that it's shown as an attachment in gmail as well,
> > even though it's not an attachment. I have no idea why :)
>
> The archive code appears to actually try to handle the case of multiple
> inline
> plain text attachements, from what I can see:
>
> https://git.postgresql.org/gitweb/?p=pgarchives.git;a=blob;f=loader/lib/parser.py;hb=HEAD#l381
> 381 # If we have already found one text/plain part, make all
> 382 # further text/plain parts attachments
> 383 if self.attachments_found_first_plaintext:
>
>
> So there's something more than just the content-disposition: inline; going
> on
> I think?
>

Huh. I think you're right. I guess I was just reading it too quickly.

And yup, there's the bug.

Line 388 gets the payload in this case -- which returns in type "bytes".
Line 395 verifies that it's a string (which it isn't).

This is a bug in the conversion to python 3.

I've applied a fix and re-parsed the message.

Thanks for being persistent!

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>