Hi! I just synchronized 300,000 files between Windows and Asustor NAS (docker). Mostly, it’s fine. But some files on the NAS have chunks of random garbage (16 byte repeating pattern, different each time the file is written) instead of zeros. Chunk size seems to be a multiple of 0x1000, offset is also a multiple of 0x1000 or larger.
Copying these file directly by hand does not corrupt them. My impression therefore is that Syncthing forgets to zero data chunks on the target if there are larger chunks of zeros in a source file. Source here is Windows, target is Asustor NAS.
That’s fascinating, I wonder what the Asustore is doing here. Syncthing by default uses sparse files, which indeed means blocks of zeroes are not explicitly written. I’ve never heard of this not actually resulting in zeroes when read; my gut feeling says this is an operating system bug. Nonetheless you can disable sparse files in the Syncthing config.
Thanks for the quick reply! I can confirm that the problem is with sparse files. The NAS folder is an eCryptfs encrypted share. eCryptfs expands sparse files. I do not know where the bug lies, but I do believe that this is a potentially security relevant bug. It is hard to detect (noticed only if you re-create a share or compare files with an external program) and difficult to mitigate (I had to change the defaults in config.xml because switching off sparse file after creation of the share is too late). eCryptfs is used e.g. by Asustor and Synology to encrypt folders (have not tested whether they are vulnerable as well).
Thanks. Seems to be another Asustor problem. “truncate -s 100KB sparse.img” in an ecryptfs encrypted folder produces garbage in Asustor but works fine (zeros) in Synology. The Asustor NAS was my worst decision in a long time, good hardware, barely usable software.
eCryptfs should un-sparse any file written to it. The behaviour your’re seeing seems consistent with the un-sparsing not working. Specifically if the file is actually sparse on the backing filesystem, eCryptfs will read zeros, “decrypt” them using the encryption key, and present the resulting garbage to the reading program.
You could maybe check if the underlying file is really sparse or not. It might be a bug with ecryptfs not properly zeroing files under load.