** Also affects: linux-meta (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
Cutting or copying files on btrfs to ec
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 Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/13053
** 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 Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1305335
Title:
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 Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1305
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
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
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 Desktop
Packages, which is subscribed to nautil
** Tags added: kernel-bug-exists-upstream
--
You received this bug notification because you are a member of Desktop
Packages, 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
Status in
@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 Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/
@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
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
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 Desktop
I checked the mainline 3.11 kernel and it has the bug (as well as 3.13,
3.18 and 3.19, based on the other comments), so I would say it is not a
regression.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.l
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Tyler Hicks (tyhicks)
** Changed in: ecryptfs
Assignee: (unassigned) => Tyler Hicks (tyhicks)
** Changed in: ecryptfs
Importance: Undecided => Critical
--
You received this bug notification because you are a member of Desktop
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)
The `cp --reflink=always test test.bak` is always issuing the
BTRFS_IOC_CLONE ioctl, even on non-btrfs filesystems. eCryptfs passes
ioctls down to the lower filesystem but I suspect that it should stop
doing that altogether or possibly only allow a white list of known good
ioctls.
--
You received
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.
We might be able to handle this in
fs/ecryptfs/file.c#ecryptfs_unlocked_ioctl, which gets passed the btrfs
io
ecryptfs_unlocked_ioctl gets passed the (higher) target file struct as
the first argument, the command as the second, and the source file
descriptor as the third argument. It looks like the source file
descriptor has already been converted to the lower file if it is
associated with a higher file in
** Tags removed: kernel-key
** Tags added: kernel-da-key
--
You received this bug notification because you are a member of Desktop
Packages, 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 l
> 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
** 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 Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/13053
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
24 matches
Mail list logo