ebDAV (Synology): files read through RaiDrive contain wrong 16–32 KB blocks (served from cache)

Hello,

we see reproducible data corruption when reading files through a RaiDrive WebDAV drive. The files on the NAS are intact, but RaiDrive serves wrong data for parts of some files.

Environment

  • RaiDrive Mount 2026.6.25, Dokan 231(400)
  • Windows 11 Pro, build 26200
  • Synology NAS, WebDAV over HTTPS, wired LAN, internal address, TLS 1.3
  • Drive config from service.log: LOCK False : CHECKREMOTEONGETFILEINFO False : KEEPCACHE False : ASYNCUPLOAD False : BACKGROUND REFRESH True
  • Explorer file preview enabled, Windows Defender only

Symptom

iPhone JPEGs (4–7 MB) opened from the RaiDrive drive appear partly grey in Windows Photos and Paint. The same file opened via SMB from the same NAS on the same PC is complete and correct.

[>>> HERE: drag in “05 Windows Photos - IMG_1702 grey.webp” <<<]

ACDSee shows only a small glitch stripe at the same position, because it resyncs at the JPEG restart markers. So the problem may go unnoticed by other users.

[>>> HERE: drag in “04 ACDSee - IMG_1702 small glitch.webp” <<<]

What we measured (SHA-256 and byte-by-byte comparison, SMB vs. RaiDrive)

Size (bytes) Wrong range via RaiDrive
7,201,331 409,600 – 434,176 (24 KB)
6,961,010 589,824 – 610,304 (20 KB)
4,322,180 557,056 – 589,824 (32 KB)
4,627,072 from 1,966,080
3,011,544 from 638,976
  • The file size is always correct. Only one contiguous block in the middle is wrong.
  • All wrong ranges are aligned to 4096 bytes and are 16–32 KB long.
  • The wrong data is not zeros, and it does not match any other file in the same folder.
  • Reading the file again through RaiDrive returns exactly the same wrong data, so it is cached.
  • Disconnect/reconnect (cache emptied) fixes it. All files are then read correctly.
  • It comes back within hours. We verified about 2,700 photos as correct, and a few hours later several of them were again served with wrong blocks, while the NAS copies were unchanged.

Permanent damage

If a corrupted file is copied through the RaiDrive drive into another folder, the corrupted version is uploaded to the NAS. During these copies, service.log shows several Rename File Error : Target File Already Exists.

Notes

  • Colleagues on older RaiDrive versions have not noticed this so far. Since 2026.6.7 introduced “Download: sequential read performance”, we suspect a regression in the read-ahead or cache logic.

Questions

  1. Is this a known issue in 2026.6.x?
  2. Which version or setting do you recommend for WebDAV with Synology (file preview, check file properties immediately, file lock)?
  3. Can RaiDrive verify cached data (e.g. ETag or checksum) before serving it?

Logs and sample files (correct vs. corrupted version) can be sent privately to support.

Thanks!

Please re-test using the nightly build version provided below.

The behavior may differ because the handling of file system events and network operations has been modified.

For information regarding various settings, please refer to the documentation below:

To ensure rapid processing of file system requests, RaiDrive does not perform independent data verification.
However, it does compare remote file information with cached information.

Please let us know the results after testing. If any issues arise, please send your logs to support@raidrive.com, and we will review them and get back to you.

RaiDrive Support