The files that it happens to are a few GiB in size. It doesn't fail immediately, rather when I read it with dd status=progress the first time it reads a bit into the file (a few MiB or over a hundred MiB, depending on the files, but it seems to always be the same distance for the same file), and then throws "No such file or directory". Based on strace it gets ENOENT from a read call, after it's already read megabytes of data from the same fd.
On subsequent reads, it gets through the whole file. Only, it doesn't really, because the resulting content is wrong. So it never truly reads the whole file, but only sometimes throws an error (when it's not in disk cache?). The same file is always read correctly with ntfs-3g.
Also, not sure if related, but after I've mounted and unmounted a few times with ntf3 and ntfs-3g, ntfs3 starts throwing errors saying:
"mount: /windows/d: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error."
and refuses to mount it unless I add -o ro. It still works properly in ntfs-3g.
The filesystem has compression enabled, in case that matters ("Compress this drive to save disk space" is checked in the file system settings in Windows), though the files should be incompressible, as they're gzipped or random.
I tried running chkdsk from Windows, but that did not fix it (except I think it temporarily got rid of the "wrong fs type..." mount error).
I can reproduce it by dd:ing 4 GiB of /dev/urandom to a file and copying it onto the NTFS partition while mounted with ntfs-3g, and then trying to read the file while mounted with ntfs3.
My full mount options are: ntfs-3g: fmask=113,dmask=002,gid=100,noatime,windows_names,compression ntfs3: iocharset=utf8,fmask=113,dmask=002,gid=100,noatime uname -r: 5.17.2-1-default rpm -q ntfsprogs: ntfsprogs-2021.8.22-2.2.x86_64 rpm -q ntfs-3g: ntfs-3g-2021.8.22-2.2.x86_64
Attachment:
OpenPGP_0x13A0FDC40794CE02.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
