Comment 129 for bug 509180

See also comments #104 and #128.

In parallel with the looping md5sum of everything in the 17G ecryptfs
read-only partition described above, I picked one of the files that
had produced different md5sums on different runs and wrote this script
to repeatedly md5sum the same file over and over (filename shortened
for clarity):

    #!/bin/sh -u
    # -Ian! D. Allen - <email address hidden> - www.idallen.com

    f=filename
    set -- $( md5sum "$f" )
    start=$1
    while : ; do
 set -- $( md5sum "$f" )
 if [ "$1" != "$start" ] ; then
     echo "$start != $*"
 fi
    done

Over the course of two days running my tests, the above script produced
two outputs, indicating two times when that one file was read and had
a different checksum from when the script started:

c68292cceb13f21de7375c46c0ffdf9a != 58a90406649b9e795f9e1e6b34b806f8 filename
c68292cceb13f21de7375c46c0ffdf9a != 58a90406649b9e795f9e1e6b34b806f8 filename

This file is on a read-only ecryptfs partition. The md5sum should not
be changing.

I note that when the md5sum does change, it always changes to the same
"other" value; it's not random.

In my tests, the ecryptfs corruption seems to happen only when reading
from files with more than one link.

The file itself is 1132 bytes. Its encrypted base file is 12288 bytes.