I believe this is a problem that Dustin has ran into before. It is due to ext4 and zero-length files (http://thunk.org/tytso/blog/2009/03/12 /delayed-allocation-and-the-zero-length-file-problem/).
When a file is created in an eCryptfs mount, we go ahead and create the file in the lower filesystem and write out the eCryptfs metadata (encrypted file key, decrypted file size, etc.). Anytime that a file open is performed, we expect that metadata to be present or we consider it a non-eCryptfs file and ignore it by returning -EIO. You are seeing the warning message from an open on a file that doesn't have the proper eCryptfs metadata. We may be able to let the zero-length files slide and generate and write the header information on the first file write. The problem with this is that it may break the way that users expect ecryptfs_passthrough to work. You can touch a file in the lower filesystem (creating a zero length file) and then any subsequent writes from the eCryptfs mount point will be passed through instead of encrypting the data. That may just be a little trick that I do for testing and not something that any users actually do. I need to think about that a little more. -- Ecrypt errors in dmesg https://bugs.launchpad.net/bugs/372014 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
