> 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