Latest update breaks saving parts

Latest update breaks saving parts

[David S. Goldberg]

After updating this morning (8/10 around 0830 EDT), I've tried to save
a couple of attachments to disk.  I end up with an error thrown (Error
with message).  I suspect the following may have some faulty logic in
it:

2001-08-09  Simon Josefsson  <jas@extundo.com>

        * mm-decode.el (mm-insert-part): Return decoding success status.
        (mm-save-part-to-file): Error if decoding failed.

Saving the entire message and running metamail on it successfully
extracts the attachment.  Also I now get this error trying to extract
attachments from older messages that were successful prior to this
update.  Finally, one attachment was an image/jpeg which displayed
just fine inline but throws the error when trying to save.  I think
the decoding function (presumably mm-decode-content-transfer-encoding)
must therefore be succeeding but not returning what an expected value
for success.  I've been unable to follow the code well enough to
understand it for sure.

Thanks,
-- 
Dave Goldberg
dsg@world.std.com

Re: Latest update breaks saving parts

[Barry Fishman]

dsg@world.std.com (David S. Goldberg) writes:

> After updating this morning (8/10 around 0830 EDT), I've tried to save
> a couple of attachments to disk.  I end up with an error thrown (Error
> with message).  I suspect the following may have some faulty logic in
> it:
>
> 2001-08-09  Simon Josefsson  <jas@extundo.com>
>
>         * mm-decode.el (mm-insert-part): Return decoding success status.
>         (mm-save-part-to-file): Error if decoding failed.

I am seeing the same thing.  It happens almost all the time but not
for every jpeg attachment.  The temporary file (/tmp/emm.*) is just
fine, and not truncated, and "K v" to display works just fine, but "K
o" signals:

Signaling: (error "Error with message")
  signal(error ("Error with message"))
  error("Error with message")
  mm-save-part-to-file((#<buffer  *mm-uu*> ("image/jpeg") x-uuencode ("/tmp/emm.173009lQ/INDEX_S'more1702.JPG" . #<buffer  *mm*>) ("inline" (filename . "INDEX_S'more1702.JPG")) nil nil nil) "~/work/INDEX_S'more1702.JPG")
  mm-save-part((#<buffer  *mm-uu*> ("image/jpeg") x-uuencode ("/tmp/emm.173009lQ/INDEX_S'more1702.JPG" . #<buffer  *mm*>) ("inline" (filename . "INDEX_S'more1702.JPG")) nil nil nil))
  gnus-mime-save-part()
  call-interactively(gnus-mime-save-part)
  byte-code("\b‰\x18A@)\x19Å	‰\x1a@)!ˆ	‰\x1aA@:ƒ\x1f
  gnus-mime-button-menu((down-mouse-3 (#<window 89 on *Article*> 255 (225 . 113) -29045936)))
  call-interactively(gnus-mime-button-menu)

Barry

Re: Latest update breaks saving parts

[David S. Goldberg]

> After updating this morning (8/10 around 0830 EDT), I've tried to save
> a couple of attachments to disk.  I end up with an error thrown (Error
> with message).  I suspect the following may have some faulty logic in
> it:

> 2001-08-09  Simon Josefsson  <jas@extundo.com>

>         * mm-decode.el (mm-insert-part): Return decoding success status.
>         (mm-save-part-to-file): Error if decoding failed.

[...]

Same still exists after updating this morning.  My workaround:
checkout mm-decode.el version 6.48.
-- 
Dave Goldberg
dsg@world.std.com

Re: Latest update breaks saving parts

[Simon Josefsson]

dsg@world.std.com (David S. Goldberg) writes:

> Same still exists after updating this morning.  My workaround:
> checkout mm-decode.el version 6.48.

Hm.  What kind of content-transfer-encoding is the part in?  (Could
you forward a sample to me?)  Maybe you could `edebug-defun' the
function and step through it to see how the return-value is
calculated.

Re: Latest update breaks saving parts

[David S. Goldberg]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

> dsg@world.std.com (David S. Goldberg) writes:
  (new email address, same person, and the wonders of auto-forwarding
  put it all in the same place anyway :-)

>> Same still exists after updating this morning.  My workaround:
>> checkout mm-decode.el version 6.48.

> Hm.  What kind of content-transfer-encoding is the part in?  (Could
> you forward a sample to me?)  Maybe you could `edebug-defun' the
> function and step through it to see how the return-value is
> calculated.

It's in base64.  Most of the stuff is work related so I've cobbled up
a sample that shows the same problem.  I edebug-defun'ed
mm-save-part-to-file and mm-insert-part, base64-decode-region and
mm-decode-content-transfer-encoding.  Ultimately it looks like
base64-decode-region returning nil is the problem, and that function
appears to want to return nil no matter what.  My base64.el is from
the most recent mail-lib XEmacs package.  I'll note that this happens
whether or not I set base64-decoder-program, which I normally do since
mmencode -u is typically faster.  I turned that off temporarily for
testing this but it didn't help and, in fact, made edebugging
base64-decode-region that much more time consuming.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

[-- Attachment #2: Type: message/rfc822, Size: 877182 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 51 bytes --]

test
-- 
Dave Goldberg
david.goldberg6@verizon.net

[-- Attachment #2.1.2: Hops_2001.jpg --]
[-- Type: image/jpeg, Size: 647656 bytes --]

Re: Latest update breaks saving parts

[David S. Goldberg]

Dammit, I meant to only reply to Simon on that last one.  I apologize
for taking up everyone's bandwidth there.
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: Latest update breaks saving parts

[Lars Magne Ingebrigtsen]

dsg@world.std.com (David S. Goldberg) writes:

> Same still exists after updating this morning.  My workaround:
> checkout mm-decode.el version 6.48.

Ok.  For now, I've backed out the call to `error' in the saving
function. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen