On a btrfs file system with a mounted ecryptfs folder, if you try to clone a file that is not in the ecryptfs folder into the ecryptfs folder (eg using cp --reflink=always or cp --reflink=auto), the clone operation reports success but the resulting higher file is zero bytes long and accessing its lower file results in an I/O error, ie the data in the copied file is completely lost.

This is especially an issue for any application using gnomevfs (eg nautilus), because the underlying libglib package automatically attempts a clone operation (since v2.36.4, anyway). Worse still, I've seen it completely lose the data when doing a move - it seems that does a copy (which produces the corrupted zero-byte file) then a delete operation on the original.

What seems to be happening is that the userspace application is calling the btrfs ioctl clone operation and passing the higher ecryptfs file as the target path, but by the time btrfs_ioctl_clone is called in the kernel the target file structure actually points to the lower ecryptfs file. So I suspect that ecryptfs is intervening at some point to convert the target from higher to lower. This means it works if you are cloning one file inside the ecryptfs mount to another file inside the same ecryptfs mount, but in this particular case it shouldn't do that.

There's more info at https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1305335 and in particular at https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1305335/comments/20, where there's a test script that demonstrates the problem.