** 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:
Cutt
** 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 manage
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 in
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 copy
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 anot
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.
https://bugs.launchpad.n
** 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:
Cutt
> 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 ma
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 de
** 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 no
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)
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
B
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) fai
@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 fo
@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
Tit
** 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 abo
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, assumin
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.
htt
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 i
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 BTRFS
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 kernel[
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:
Cut
** 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 copyi
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:
Cutt
** 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 in
26 matches
Mail list logo
