Comment 16 for bug 1305335

The 3.19 kernel still has the problem.

You can reproduce it by copying a test file from say /home into an encrypted home directory using --reflink:

echo test > /home/test
cp --reflink=always /home/test ~
ls -l ~/test # This shows 0 bytes

This command, however, copies the file correctly, assuming you haven't aliased cp to use reflink:

echo test > /home/test
cp /home/test ~
ls -l ~/test # This shows 5 bytes

nautilus is using the g_local_file_copy library command in glib, which since automatically applies reflink since 2.36.4 (libglib2.0-bin is at 2.43.4-1 in Vivid). See the comment at http://upstream.rosalinux.ru/changelogs/glib/2.36.4/changelog.html, where it lists "Btrfs clone/reflink ioctl support in g_local_file_copy " as one of the changes.

So one solution would seem to be to modify the copy functionality to disable reflink (or disallow the copy) if it detects it is copying into a mounted ecryptfs directory (eg using /proc/mounts) from a directory that is not in the same mount.

Presumably ecryptfs intercepts the copy request, so perhaps the check should be done in ecryptfs?