rfjakob
commented
7 months ago Hi, thanks for the report!
I checked the TestFileHoleCopy test, and it compares the md5 of the original and the copy here: https://github.com/rfjakob/gocryptfs/blob/1766df8475355a49595542e1cd52e63ace79bc74/tests/plaintextnames/file_holes_test.go#L58
Looks like it loses some file holes (i.e. wastes space on disk), but there's no corruption.
I checked out the current master and compiled it successfully. After running the tests, I see that TestFileHoleCopy and TestAccessVirtualDirIV are failing. I wondered if my xfs fs could be an issue. So, I created an ext4 ramdisk, ran the tests there, and the same tests are failing.
test-without-openssl.bash -v output on the xfs fs. xfs-test-v.log
Fedora 39 kernel 6.6.3 fuse3 3.16.1 gocryptfs v2.4.0-12-g1766df8 without_openssl; go-fuse v2.4.0; 2023-12-07 go1.21.4 linux/amd64
Out of curiosity, I booted up a fresh Debian 12.2 VM to compile and run the test suite. The TestFileHoleCopy passes but TestAccessVirtualDirIV fails with the same error as in the linked xfs-test-v.log.
Debian 12.2 kernel 6.1.0 fuse3 3.14.0 gocryptfs v2.4.0-12-g1766df8 without_openssl; go-fuse v2.4.0; 2023-12-07 go1.19.8 linux/amd64
The failing file hole test seems concerning as it looks like possible data corruption. Whereas the access virtual dirIV appears related to a permission issue.
Let me know if more information is wanted. Thanks in advance for looking into this.