Bug 90304 – Disk full results in Thunderbird creating weird "indestructible" emails

• Product: Gentoo Linux
• Status: RESOLVED NEEDINFO

[Description Finn Higgins 2005-04-24 16:24:29 UTC]

I had a disk fill up yesterday while running Thunderbird 1.0.2, thanks to the inordinate amount of space OO.o uses when compiling.  This created exactly one hundred and six "indestructible" emails in my inbox.

They are initially marked as unread when I open my inbox.  I can select them and mark them read, but any event that triggers a refresh of the mailbox (checking mail, restarting Thunderbird etc) returns those messages to an unread state.

Worse, every time Thunderbird checks mail while those messages are marked as unread, it adds 106 to the total "unread" count on my inbox.  Last time I looked it thought I had more than five thousand unread messages.  Going to another mailbox and coming back results in this count returning to 106.

Reproducible: Always
Steps to Reproduce:
1. Open Thunderbird with my mailbox in its new corrupt state
2. See 106 unread messages
3. Go to inbox, Edit->Select->All
4. Message->Mark->As Read
5. Close Thunderbird
6. GOTO 1.

Note these reproduction steps are only valid on my new, corrupted inbox.  I'm unable to reproduce the state that caused this corruption, but it was almost certainly due to a disk-full problem as it was first observable right after a bunch of other things complained about running out of space.  This should maybe be logged as a separate bug, but I'm not up to testing it extensively right now and I'm running a different version of Thunderbird from the 1.0.2 release that caused the corrupted data.

This bug deals with the way Thunderbird is handing the mailfile rather than the cause of the corruption.
Actual Results:  
I had 106 unread messages in my inbox, again.  They're all very old, by the way.
 The above steps also demonstrate a similar reluctance to let me deal with those
messages if I try deleting them, marking them as junk or anything else.



Expected Results:  
Thunderbird should allow me to dispose of those messages, or at least flag them
read.

I have since reverted to 1.0 as 1.0.2 has been MORE buggy than 1.0 (I have
another bug in here relating to the GUI rendering).  Reverting fixed my other
bug but this one remains an issue.

I'm fairly sure this occurred as a result of the disk filling up, but having had
a search over on Bugzilla I can't seem to find anything that's documented the
problem and verified it as a bug.

There is a thread over here at the Mozillazine that documents a few other people
with similar problems, plus a link to a seemingly related upstream bug:

http://forums.mozillazine.org/viewtopic.php?t=249528

--

$ emerge info
Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130,
glibc-2.3.4.20041102-r1, 2.6.9-gentoo-r13 i686)
=================================================================
System uname: 2.6.9-gentoo-r13 i686 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar  2 2005, 02:25:42)]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.5, 1.6.3, 1.8.5-r3, 1.7.9-r1, 1.4_p6, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r7
sys-devel/libtool:   1.5.14
virtual/os-headers:  2.6.8.1-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
LANG="en_AU.UTF-8"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X aac acpi alsa apm arts avi berkdb bitmap-fonts bonobo cdr crypt cups
curl divx4linux dvd emboss encode esd fam foomaticdb fortran gdbm gif gnome
gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile imagemagick imlib ipv6 java jpeg
junit libg++ libwww mad mikmod motif mozilla mp3 mpeg msn mysql ncurses nls nocd
offensive ofx ogg oggvorbis opengl oss pam pcre pdflib perl php png pnp python
quicktime readline samba sdl session slang sndfile spell ssl svg svga tcpd tetex
tidy tiff truetype truetype-fonts type1-fonts unicode usb videos vorbis wmf
xinerama xml xml2 xmms xosd xprint xv xvid yahoo zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY

[Comment 1 Carsten Lohrke (RETIRED) 2005-04-24 16:58:03 UTC]

mozilla.org applications are known not to deal well with your data if the diskspace is filed up. If you'd have had - and that's good practice - /,/tmp,/var,/usr,/home,/opt on different partitions, you probably were not run into this issue.

[Comment 2 Finn Higgins 2005-04-25 01:09:28 UTC]

All very true, but there's some logic behind the current arrangement.  

Suffice to say there's a lot of other stuff on this drive and any serious separation of partitions would have resulted in major space balancing headaches - especially when things like OO.o seems to take somewhere in the gigabytes of disk space just to build (no, really - I was just watching it, the disk dropped from 4.2gb free to 1.9gb, then came back up at the end of the OO.o build).  It's not a big disk, so leaving a few gig free just so OO.o can have a bit more temporary space at compile time isn't really viable.  If anything that would probably make /home run out more often due to the horrendously restricted size it would have to be to allow other parts of the system to compile properly.

Anyway, all of that aside - I seem to have found a viable solution.  I can still import the suspect mailbox into Evolution without problems, so that leaves me two options:

1) Start using Evolution instead, or
2) Move all my email there and then migrate back again.

All the hassle Thunderbird has caused this week may result in #1 being the more appealing option after taking the effort to get the mail over there.  Either way, it's at least a workaround for the bug.

[Comment 3 Jakub Moc (RETIRED) 2005-12-23 06:48:26 UTC]

Honestly, I don't think Gentoo could do much here. If this is still an issue with up-to-date TB versions, then please file a bug upstream and post the URL here.