On Wed, Sep 04 2013, Austin Clements <amdragon at MIT.EDU> wrote: >> Now, some mime parts have subparts and to avoid overwriting the >> sub-part data notmuch checks and if part data is already recorded it >> does not overwrite it. >> >> Now with lazy part handling this could fail: there is already part >> data stored. In the common case it works as the part type information >> was stored when the lazy-part button was inserted. However, this fails >> if the lazy part has sub-parts: notmuch had no idea these existed >> until the lazy part insertion. > > This says that things fail when a lazy part has sub-parts, but not > what the failure is. What is the failure? Can you give a specific > sequence of events and conditions that leads to and demonstrates the > failure? > > (I ask not just for commit posterity, but because I actually don't > know, though I may have figured it out after writing the comment > below.)
Hey, Austin. Here's an example of a mail that is effected the issue: ???multipart/alternative 896783 bytes ???text/plain 379 bytes ???multipart/related 892556 bytes ???text/html 1236 bytes ???image/jpeg inline [photo.JPG] 890841 bytes The multipart/related part is initially hidden. Without Istvan's patch, there would be no button at all for the image/jpeg part, even when the multipart/related is exposed. With Istvan's patch the image/jpeg button is there, but without Mark's patch the button would actually reference the entire multipart/alternative part, instead of just the image/jpeg. If I tried to save the image/jpeg I would get the entire multipart/alternative mime structure in plain text. jamie. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130904/9acba2bd/attachment.pgp>