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? -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1305335 Title: Cutting or copying files on btrfs to ecryptfs results in data loss To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/1305335/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
