Comment 14 for bug 509180

Well if you're just trying to reproduce in a testcase, you can
probably just do a
custom ecryptfs mount as root:

mkdir testcrypt, testplain
cat > testme.sh << EOF
mount -t ecryptfs <options> testcrypt testplain
echo ab >> testplain/ab
umount testplain
EOF
chmod ugo+x testme.sh

for i in `seq 1 100`; do
  ./testme.sh
done

On Fri, Apr 9, 2010 at 2:38 AM, Erik Carstensen <email address hidden> wrote:
> Do you know of any way to remount an ecryptfs mount without first having
> to log out? That would suffice as a workaround most of the time, and
> would make this bug a lot less annoying for me.
>
> --
> ecryptfs sometimes seems to add trailing garbage to encrypted files
> https://bugs.launchpad.net/bugs/509180
> You received this bug notification because you are a member of eCryptfs
> Developers, which is subscribed to eCryptfs.
>
> Status in eCryptfs - Enterprise Cryptographic Filesystem: Triaged
> Status in “linux” package in Ubuntu: New
>
> Bug description:
> Quite frequently (about once per month), a file in my ecryptfs-encrypted home directory gets a few KiBs of extra trailing garbage bytes (it's usually padded up to about 12 KiB). I have only noticed the error in git repositories so far, probably because git creates a huge number of files, and because it doesn't tend to ignore trailing garbage anywhere.
>
> The trailing garbage usually consists mostly of zero bytes; sometimes I have also seen it contain a copy of parts of the original file.
>
> If I re-mount the ecryptfs volume (by logging out and logging in again), the trailing garbage always disappears; this is why I think it's caused by an ecryptfs bug. I cannot rule out a faulty RAM, either (I have only reproduced it on my laptop, which doesn't have ECC RAM).
>
> I'm using x86-64 Ubuntu 9.10, my ecryptfs volume resides on an ext4 partition.
>
> I understand that it's impossible for you to reproduce the problem given this report, but I'm willing to put some effort in tracking down the cause of this. Do you have any ideas on how I can extract useful debugging information the next time the problem occurs?
>
>
>