Slight problem if file size can’t be reduced! 50% chance the newer file will be smaller than the existing one (ok maybe 25% in reality). So can then not be updated in place. Thumbs down for windows on this aspect. I would assume this corruption is due to the file management system caching file data in ram, and there being a bug or functionality restraint in how that is implemented between processes.
I can only imagine the complexity involved in getting around that issue/bug in windows! Clearly not the job of a “external” program to manage anyway.
Is there some method to do a bug report to microsoft?
In-memory caching, temporary files and perhaps other things make successfully overwriting an open file hit or miss on Windows.
Seems like it’s more of a deliberate design decision rather than a bug.
I was curious if a copy-on-write filesystem would work, so after a bit of searching I stumbled across WinBtrfs, a native btrfs driver for Windows. It solves multiple issues but is still constrained by Windows not allowing renaming of files with open file handles.
Good find! Seems like it’s too early for that to be a daily driver yet. With defrag etc on the todo list. But very promising!
If it doesn’t suffer from data corruption during writing in place, it might be a long term solution to be able to have syncthing multi-process/collaboration compatible on windows sometime in the future!