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
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.
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.
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.
