Thanks. I agree that reporting zero because the bytes are accounted for
in the underlying FS is not the right answer, since this is a different
mount point, and it is understood that overlay mounts can cause the same
files or disk space to appear twice.
Any chance of having a bug fix in karmic,
The masses have spoken :)
** Attachment added: [PATCH] eCryptfs: Add getattr function
http://launchpadlibrarian.net/35088311/0001-eCryptfs-Add-getattr-function.patch
--
du reports newly created files on ecryptfs as empty
https://bugs.launchpad.net/bugs/390833
You received this bug
One could argue that the current du output is correct because the
ecryptfs really requires zero bytes for storing the files (because it's
using the underlying file system for actual storage).
However, that prevents users from from using du or any similar tool
for figuring out which files and/or
Oh, nice find!
Perhaps we can document our way around this bug...
--
du reports newly created files on ecryptfs as empty
https://bugs.launchpad.net/bugs/390833
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
FYI du with --apparent-size shows the right logical sizes, it's the
sparse block etc support that tries to figure out the underlying storage
taken that is the problem.
--
du reports newly created files on ecryptfs as empty
https://bugs.launchpad.net/bugs/390833
You received this bug notification
** Changed in: ecryptfs-utils (Ubuntu)
Status: New = Triaged
** Changed in: ecryptfs-utils (Ubuntu)
Importance: Undecided = Medium
--
du reports newly created files on ecryptfs as empty
https://bugs.launchpad.net/bugs/390833
You received this bug notification because you are a member
** Changed in: ecryptfs
Status: Confirmed = In Progress
--
du reports newly created files on ecryptfs as empty
https://bugs.launchpad.net/bugs/390833
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
** Changed in: ecryptfs
Importance: Undecided = Medium
** Changed in: ecryptfs
Status: New = Confirmed
** Changed in: ecryptfs
Assignee: (unassigned) = Tyler Hicks (tyhicks)
** Tags added: kernel
--
du reports newly created files on ecryptfs as empty
I'm also having this problem on Jaunty:
$ mount | grep home
/dev/mapper/MAIN_VG-HOME_LV_crypt on /home type ext3 (rw)
/home/user/.Private on /home/user type ecryptfs
(ecryptfs_sig=ace5d3dc7966c556,ecryptfs_fnek_sig=c0bd3cca6d89c7fd,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)
gvfs-fuse-daemon on
Also, please note, running sync doesn't fix the problem:
$ du -sh test123
0 test123
$ sync
$ sudo sync
[sudo] password for user:
$ du -sh test123
0 test123
--
du reports newly created files on ecryptfs as empty
https://bugs.launchpad.net/bugs/390833
You received this bug
The question expired, but IMO this is most definitely a bug, and a
pretty important one at that.
** Changed in: ecryptfs
Status: Invalid = New
** Changed in: ecryptfs-utils (Ubuntu)
Status: Invalid = New
--
du reports newly created files on ecryptfs as empty
I just wanted to add to this discussion/report my own experience with
this bug. It seems that the issue occurs not just between sync, but even
after a reboot/remount.
I have an ecryptfs-mounted home directory, within which everything
appears to be 0 bytes. However, I *can* read the files and they
Hello, thanks for the bug report.
I'll leave the definitive answer to Tyler Hicks, the upstream kernel
maintainer, but I'll try to field this question as best as I can.
Basically, there is a bit of time where the new file exists only in
kernel memory, before it gets synced to disk. You might
13 matches
Mail list logo
