https://github.com/rfjakob/gocryptfs/issues/304 :
A second minor issue is that `if bytes.Equal(buf, allZero) {` compares the whole
buffer, although the last read could have been shorter. This could trigger the
"skip file hole" code at the end of a file although there isn't any hole to
skip.
When running as a regular user, error EACCES does not necessarily mean that the
file/directory/xattr is corrupt, but just that we do not have sufficient access
permissions. Add a hint that running as root can be used to check everything.
Fixes: https://github.com/rfjakob/gocryptfs/issues/309
The exact ciphertext block number (4KiB granularity) is
already printed in the doRead message. Don't cause
confusion by printing the 128KiB-granularity offset as
well.
doRead 767: corrupt block #4: stupidgcm: message authentication failed
fsck: error reading file "pa/d7/d14/f10c" (inum 767): 5=input/output error
If we encounter a 128KB block of zeros, try to skip to the next
data section by calling File.SeekData().
This fixes xfstests generic/285, which creates a 17TB sparse file,
and runs fsck afterwards. Without this optimization, fsck would
take ages.
OpenDir and ListXAttr skip over corrupt entries,
readFileID treats files the are too small as empty.
This improves usability in the face of corruption,
but hides the problem in a log message instead of
putting it in the return code.
Create a channel to report these corruptions to fsck
so it can report them to the user.
Also update the manpage and the changelog with the -fsck option.
Closes https://github.com/rfjakob/gocryptfs/issues/191
Most corruption cases except xattr should be covered.
With test filesystem.
The output is still pretty ugly. xattr support will
be added in the next commits.
Jakob Unterwurzacher