Comment 5 for bug 957843

I'm copying a part of my comment on bug #509180, because in fact what I'm seeing on my systems is what's described in this bug report here.

In short, I'm also seeing the "0-length lower file on ext4 leads to IO Error in mounted ecryptfs" bug. It's truly shocking that Ubuntu 12.04 LTS is shipping with this pathological behaviour. At least 247 of my files are at risk. Many users could be losing data and not even know about it.

I don't dare delete the lower files, because I'm not sure what's going to happen to the upper files, and then Dropbox might sync that to all my other copies. I've currently stopped using the two laptops in question.

Either a SRU needs to be done ASAP, or the option during installation to encrypt one's home directory needs to be disabled (possibly only when using ext4).

More information on one of my laptops:

$ uname -a
Linux cpbotha-e6410 3.2.0-24-generic #38-Ubuntu SMP Tue May 1 16:18:50 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ find $HOME/.Private/ -size 0c -exec ls '{}' \; | wc -l
253

Indeed, my dropbox is stuck on indexing 247 files (this is how I noticed). When I go to one of the files in question:

$ ls -la envedit.exe.manifest
-rw-rw-r-- 1 cpbotha cpbotha 0 May 14 17:17 envedit.exe.manifest

$ cat envedit.exe.manifest
cat: envedit.exe.manifest: Input/output error

... and then in my dmesg:

[ 6554.071505] Valid eCryptfs headers not found in file header region or xattr region, inode 4882470
[ 6554.071511] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

In other words, I have at least 253 files (some of them more important than envedit.exe.manifest) that are at risk.