** Changed in: ecryptfs
Status: Opinion => Fix Released
** Changed in: linux (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
** Changed in: ecryptfs
Status: Confirmed => Opinion
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ecryptfs results in data loss
To
It has been fixed for me since kernel 4.0, so yes, I think it can be
closed now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ecryptfs results
Can this ticket be closed?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to 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
Linux pratomo-X450JB 4.5.0-040500rc7-generic #201603061830 SMP Sun Mar 6
23:33:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or
Seems to be working now on my arch machine.. Great work!!!
It noticed something though:
When I move a (large) file to ecryptfs folder this now seems to happen
instantly. As I remember it (on ext4 machines) moving files would take a while
and show a progress bar, like you see when moving to
Cool, I see the patch is in 4.0-rc3 now (commit
6d65261a09adaa374c05de807f73a144d783669e).
I applied it to 3.19.1-generic and can confirm it works as advertised.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** No longer affects: nautilus (Ubuntu)
** Tags added: kernel-fs
** Changed in: linux (Ubuntu)
Status: Confirmed = Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
On 2015-02-24 04:32:21, Rocko wrote:
I think it is still useful for ecryptfs to support the btrfs clone ioctl
for the case where both source and target higher files are in the same
ecryptfs mount, since this saves disk space.
I don't like the idea of eCryptfs supporting the clone ioctl by
** Tags removed: kernel-key
** Tags added: kernel-da-key
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ecryptfs results in data loss
To manage
I don't like the idea of eCryptfs supporting the clone ioctl by default.
It would allow an attacker to discover that the files (the original and
the clone) are the same.
I agree with that reasoning.
In any case, I think that the btrfs clone operation should be disallowed
in ecryptfs as a
As a follow-up to comment #16: generally attempting to clone a file in
a non-ecryptfs folder into a mounted ecryptfs folder appears to succeed
but in fact creates a zero-length invalid target file, but going the
other way (cloning from the mounted ecryptfs folder into the non-
ecryptfs folder)
In case anyone still reads bugzilla.kernel.org, I reported this at
https://bugzilla.kernel.org/show_bug.cgi?id=93691.
** Bug watch added: Linux Kernel Bug Tracker #93691
http://bugzilla.kernel.org/show_bug.cgi?id=93691
--
You received this bug notification because you are a member of Ubuntu
Thanks for the in-depth triage of this bug, Rocko. As you pointed out, I
can easily reproduce this using cp's --reflink=always option.
I'm marking nautilus as Invalid since this is definitely an eCryptfs
bug. I'll start determining the best way to fix this issue.
** Changed in: nautilus (Ubuntu)
@whoop: If you mean that the thumbnail file length is correct but the
image file is zero bytes, the reason is that the thumbnail file isn't
copied from the non-ecryptfs folder to the ecryptfs folder. Instead, the
system stores thumbnails in ~/.cache/thumbnails. So it creates a new
thumbnail file
@Rocko: Do you have an explanation on why the thumbnail gets broken when
I cp a jpg to the ecryptfs folder? The number of bytes are correct...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
I still have a running system with this issue.
It is not an ubuntu box but Arch 64. This is a fresh install.
I stole the disk layout from the ubuntu documentation for this system:
one btrfs partition with @ subvolume for / and @home subvolume for /home.
The system also uses a vfat ESP as it is
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,
Just to note: in the example commands above, of course, /home needs to
be write-accessible to the current user, or you need to use a command
like su root -c echo test /home/test.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags added: kernel-bug-exists-upstream
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ecryptfs results in data loss
To manage notifications
Also, just to confirm, this issue only happens if you copy the files
using Nautilus? It does not happen if you copy from a terminal?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Hi Joseph,
This bug freaked me out so much I re-formatted to EXT4 and started over.
I don't have a system that I can test this on now.
The bug appeared on a completely fresh install of 14.04 beta 2 and the
bug was still present in the release.
Unfortunately, I never had any experience with
Did this issue start happening after an update/upgrade? Was there a
prior kernel version where you were not having this particular problem?
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v3.19
** Package changed: linux-meta (Ubuntu) = linux (Ubuntu)
** Changed in: linux (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
** Also affects: linux-meta (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ecryptfs results
26 matches
Mail list logo