Re: [gmime-devel] Accessing attachments including inline-parts.

[Steve Kemp <steve steve org uk>]

> The count differs because your loop is ignoring everything except
> GMimeParts:
>
>         if ( (! GMIME_IS_OBJECT( part ) ) ||
>              ( !GMIME_IS_PART(part) ) )
>             continue;

  Ahh, that makes sense.  It's just without it I see:


  (process:14845): GLib-GObject-WARNING **: invalid cast from `GMimeMessagePart' to `GMimePart'

  (process:14845): gmime-CRITICAL **: g_mime_part_get_content_object: assertion `GMIME_IS_PART (mime_part)' 
failed

  (process:14845): gmime-CRITICAL **: g_mime_data_wrapper_write_to_stream: assertion `GMIME_IS_DATA_WRAPPER 
(wrapper)' failed

  which made me think I should ignore the odd parts.

> (FWIW, the check for GMIME_IS_OBJECT is not necessary)

  Thanks.

> The multiparts can't ever be considered "attachments", so it's fine
> to ignore those. However, the message/rfc822 part might be considered
> an attachment. You can check for message/rfc822 parts by using
> GMIME_IS_MESSAGE_PART().

  Switching to "if ( ! GMIME_IS_MESSAGE_PART( parth ) ) continue;" seems
  to give similar assertions.

> Once you know a part is a GMimePart, you can simplify your code to
> get the file name by using g_mime_part_get_filename() which is a
> convenience function to do what you are currently doing. There's
> nothing wrong with your current code for that, but I figured I'd
> point out a simpler way in case you didn't know about it.

  Noted, thanks.

> That said, a GMimeMessagePart does not subclass GMimePart, so keeping
> your current code is useful if you want to handle message/rfc822
> parts as attachments.

  The ultimate goal has always been to a) discover and b) display
 arbitrary attachments.   So I guess I leaving this alone won't hurt.

> As far as bogus content sizes goes, this seems to be part of the problem:
>
> guint8 len= g_mime_data_wrapper_write_to_stream( content, memstream );
>
>
> guint8 is an 8-bit integer while
> g_mime_data_wrapper_write_to_stream() returns a size_t (which is
> typically a 32-bit integer).

  D'oh that makes a lot of sense.  I've copied that from some other
 working code I have, and managed to never spot it was a problem.
 I suspect I'm using copy_stream, and just using the size for my own
 purposes so I'd not noticed the disparity.

> You probably also don't want to use the return value of
> g_mime_data_wrapper_write_to_stream() as an exact number of bytes
> written because the data goes through a decoder transform which may
> alter the number of bytes actually written. I think I tried to make
> GMimeStreamFilter account for that, but it's probably safer to
> measure the stream length instead (the GByteArray has a 'len' struct
> member that holds the number of bytes in the 'data' struct member, so
> that's probably what you want to use).

  Thanks, that solves the problem.

> Unfortunately, even after these changes that I made locally, it still
> gave me bogus size values when printing out the CAttachment vector
> items. I think the problem is that you are creating the CAttachment
> items on the stack instead of the heap, so when the caller function
> iterates over the vector, the items are completely bogus.

  I've since fixed that to use the heap, because I spotted the same
  problem.  (Also I wanted to delete the malloced memory.)

> I'm not very sharp with c++, though, so my understanding of the
> CAttachment constructor syntax could be totally wrong - either way,
> the size values printed in your "for (CAttachment cur : result)" loop
> do not match the size values that I was printing inside of
> handle_mail(), so something isn't quite right with the vector
> results.

  It looks like I didn't setup m_size in the constructor for
  CAttachment.

> Oh, and it's not necessary to call g_mime_stream_close() if you are
> going to unref it. The final unref of the stream will close it for
> you.

  Thanks.

> Hope that helps,

  You're awesome, and very patient.  Making the obvious changes still
 hasn't gotten me the result I want, but I'm getting closer to finding
 out why.

  My advice to anybody writing a mail client is to stick with mutt .. ;)


Steve
-- 
Debian GNU/Linux System Administration
http://www.debian-administration.org/