desktop-packages team mailing list archive

[Pedro Villavicencio <pedro@xxxxxxxxxx>]

Thank you for taking the time to report this bug and helping to make
Ubuntu better. The issue that you reported is one that should be
reproducible with the live environment of the Desktop CD of the stable
release - Oneiric Ocelot. It would help us greatly if you could test
with it so we can work on getting it fixed. You can find out more about
it at http://www.ubuntu.com/download . Thanks again and we appreciate
your help.

** Changed in: evolution (Ubuntu)
   Importance: Undecided => Low

** Changed in: evolution (Ubuntu)
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evolution in Ubuntu.
https://bugs.launchpad.net/bugs/776829

Title:
  evolution corrupts attachments on save

Status in “evolution” package in Ubuntu:
  Incomplete

Bug description:
  Binary package hint: evolution

  2.28.3-0ubuntu10.2
  DISTRIB_DESCRIPTION="Ubuntu 10.04.2 LTS"
  lenovo T61 laptop

  When writing out certain attachments, Evo produces consistently
  corrupt files.  Co-workers using evo do not have the same behavior,
  and it only started a month or two ago after years of using evo.  At
  that time I attempted to get evo to read mail from an exchange server
  via IMAP, but IMAP was turned off on the server.  I deleted the
  experimental account from evo at that time.

  A given email will either produce a good or bad attachment.  It will
  be the same bytes in the attachment file each time it is produced.
  However, if I give multiple copies of exactly the same email to evo,
  each instance in evo will produce the same wrong bytes each time I try
  to save the attachment, but the bytes will differ from instance to
  instance.  This hints at a source-side as opposed to a saving-side
  problem.  However, see below on disabling spam filters.

  There seem to be two error modes.  In one, the attachment is random
  trash after some number of bytes (e.g., 526), and it is 3 bytes
  shorter than it should be.  In the other mode, a few bytes in the file
  are changed but the length is the same.  The former error is doom to
  most files.  The latter will consistently kill anything with
  compression including PDFs, but .xls and .doc files sometimes work, or
  mostly work.

  md5sum Palotai_letter*
  fcfd8d470f969915316104cf37b45c9d  Palotai_letter10.zip
  3853baa9cfa6ba4748aa524e67ce1338  Palotai_letter11.zip
  ad2f0fc6476e2e9dcb2a8bc99fe775fd  Palotai_letter2.zip
  ad2f0fc6476e2e9dcb2a8bc99fe775fd  Palotai_letter3.zip
  ad2f0fc6476e2e9dcb2a8bc99fe775fd  Palotai_letter4.zip
  ad2f0fc6476e2e9dcb2a8bc99fe775fd  Palotai_letter5.zip
  ad2f0fc6476e2e9dcb2a8bc99fe775fd  Palotai_letter6.zip
  ad2f0fc6476e2e9dcb2a8bc99fe775fd  Palotai_letter7.zip
  92c195ccd7b2646ed824e5d5600c3024  Palotai_letter8.zip
  a37a2d193981d462db1afda541e4b308  Palotai_letter9.zip
  16f86622aba1d17c03dd8be4c24927a0  Palotai_letter.zip

  Here, Palotai_letter.zip was from one mail instance, 2-7 were from
  another, and 8-11 were from different instances.  All of these files
  are the same size and have a small number of errors in them.  They
  cannot be unzipped.  For example:

  cmp -l Palotai_letter8.zip Palotai_letter9.zip 
      51 264  64

  cmp -l Palotai_letter8.zip Palotai_letter10.zip 
      49 325 327
      50 255 327

  cmp -l Palotai_letter8.zip Palotai_letter11.zip 
      49 325 327
      50 255 327
      51 264  64

  To get different instances, I set evo to read a unix mailbox that was
  not the system mailbox.  I captured a message from our server before
  it had hit evo, with all headers intact, and I copied it several times
  to the unix mailbox.  They appeared as repeats of the message in evo.

  The only configuration changes I have made are to disable spamassassin
  and bogofilter plugins and the two filtering options in mail
  preferences/junk.  Undoing those configs and restarting does not
  change the behavior.  I had been operating with those changes for
  years before this started.

  Mutt reads the attachments without a problem.  Before anyone asks, I
  am in a production environment and cannot update to a later version of
  Ubuntu until later this summer.

  Thanks,

  --jh--

  ProblemType: Bug
  DistroRelease: Ubuntu 10.04
  Package: evolution 2.28.3-0ubuntu10.2
  ProcVersionSignature: Ubuntu 2.6.32-30.59-generic 2.6.32.29+drm33.13
  Uname: Linux 2.6.32-30-generic x86_64
  Architecture: amd64
  Date: Tue May  3 19:57:59 2011
  InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
  ProcEnviron:
   PATH=(custom, user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: evolution

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/776829/+subscriptions