Package: icedove
Version: 31.0-1
Severity: serious
--- Please enter the report below this line. ---
After migrating my home directory to a 1.8TiB XFS partition, I could not
access my emails anymore. Icedove would open, but all extensions from
the profile folder were missing. The accounts were listed with the name
crossed out in the folder pane - yet the INBOX of my POP3 account (and a
single subfolder) would show up (including the mail contained
therein)... Rsyncing the profile folder from my backup one time after
another and trying various things kept me busy for most of the day...
with an AUFS union set up merging the backup root partition (ro) and
/tmp (rw), the same profile folder did work!
Digging deeper I finally found the right clues to identify the problem
cause: xfs uses 64-bit inodes by default for volumes 1TiB (and I think
BTRFS does now, too).. Icedove chokes on those.
The failing 32bit-getdents() call in strace:
access(/home/empee584/.icedove/profile/extensions, F_OK) = 0
stat64(/home/empee584/.icedove/profile/extensions, {st_mode=S_IFDIR|0770,
st_size=4096, ...}) = 0
openat(AT_FDCWD, /home/empee584/.icedove/profile/extensions,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 24
getdents(24, 0xab44401c, 32768) = -1 EOVERFLOW (Value too large for defined
data type)
close(24) = 0
gettimeofday({1407252551, 784289}, NULL) = 0
gettimeofday({1407252551, 784852}, NULL) = 0
write(1, 1407252551784\taddons.xpi\tWARN\tCa..., 10321407252551784
addons.xpi WARNCan't iterate directory /home/empe e584/.icedov
e/profile/extensions: [Exception... Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIFile.directoryEntries] nsres ult:
0x80004005 (NS_ERROR_FAILURE) location: JS frame ::
resource://gre/modules/addons/XPIProvider.jsm :: getDirectoryEntries :: line
1355 d ata: no] Stack trace:
getDirectoryEntries()@resource://gre/modules/addons/XPIProvider.jsm:1355
DirInstallLocation__readAddons()@resource://gre/m
odules/addons/XPIProvider.jsm:6889
DirectoryInstallLocation()@resource://gre/modules/addons/XPIProvider.jsm:6828
addDirectoryInstallLocation()
@resource://gre/modules/addons/XPIProvider.jsm:1775
XPI_startup()@resource://gre/modules/addons/XPIProvider.jsm:1856
AMI_callProviders()@resou rce://gre/modules/AddonManager.jsm:869
AMI_startup()@resource://gre/modules/AddonManager.jsm:745
AMP_startup()@resource://gre/modules/AddonMan ager.jsm:2318
AMC_observe()@resource://gre/components/addonManager.js:55 file:unknown
) = 1032
...
With the very same profile folder bind-mounted into ~/.icedove on an
ext4 (using 32bit-inodes):
access(/home/empee584/.icedove/profile/extensions, F_OK) = 0
stat64(/home/empee584/.icedove/profile/extensions, {st_mode=S_IFDIR|0770,
st_size=4096, ...}) = 0
openat(AT_FDCWD, /home/empee584/.icedove/profile/extensions,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 24
getdents(24, /* 61 entries */, 32768) = 2832
getdents(24, /* 0 entries */, 32768) = 0
close(24) = 0
stat64(/home/empee584/.icedove/profile/extensions/{57068FBE-1506-42ee-AB02-BD183E7999E4},
{st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0
stat64(/home/empee584/.icedove/profile/extensions/{57068FBE-1506-42ee-AB02-BD183E7999E4},
{st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0
stat64(/home/empee584/.icedove/profile/extensions/{4C9FE6FE-2C83-11DC-90B4-DC8456D89593},
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/home/empee584/.icedove/profile/extensions/{4C9FE6FE-2C83-11DC-90B4-DC8456D89593},
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/home/empee584/.icedove/profile/extensions/{CC3C233D-6668-41bc-AAEB-F3A1D1D594F5},
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(/home/empee584/.icedove/profile/extensions/{CC3C233D-6668-41bc-AAEB-F3A1D1D594F5},
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
...
chromium seemingly had the problem:
https://code.google.com/p/nativeclient/issues/detail?id=1253
64-bit icedove reportedly does work with xfs/inode64..
http://oss.sgi.com/archives/xfs/2013-07/msg00152.html
Running a 32bit distro with 1TeraByte partitions is probably rather
uncommon so I couldn't find a bug reported for this upstream..
just something similar (?) fixed up 4 years ago..
https://bugzilla.mozilla.org/show_bug.cgi?id=389087
Bug 389087: nsILocalFileUnix affected by 32bit stat/statvfs/truncate,
therefore does not work with large files
# wget https://raw.githubusercontent.com/gnb/junkcode/master/summarise_stat.pl
# perl summarise_stat.pl /usr/lib/icedove/
Summary by status
-
476 97.3% are scripts (shell, perl, whatever)
10 2.0% don't use any stat() family calls at all
2 0.4% use 32-bit stat() family interfaces only [BROKEN]
1 0.2% use both 32-bit and 64-bit stat() family interfaces [BROKEN]
3 0.6% BROKEN
List of broken files
