That’s an additionally weird factor I didn’t notice yet, and I am not sure I correctly understand now: Are you saying that it correctly writes to disk when first syncing a file, but fails (as in keeps filling up modified mem. until OOM) when continuing a sync that started already earlier (i.e. the syncthing temp file already exists)?
Also how big a file are we talking about? Can see that in the screenshot.
Also, to be 100% sure… I see the syncthing temp file in the list in the program you’re using, and I’ll take it on trust that it means the file is memory mapped. But Syncthing doesn’t do that with files it’s syncing. Is it possible this is just your antivirus trying to scan the file while syncthing is writing it, or something like that?
If disabling snakeoil (antivirus) isn’t an immediate jackpot, Process Monitor and/or DiskMon from sysinternals (now microsoft/windows) could probably provide the relevant information on what is happening with that file and by which process:
Having left it overnight, this is what I have come to…
So minimal modified memory.
As mentioned I deleted the tmp file and it’s started from scratch and is behaving itself.
AV was disabled but I already have exceptions on the windows folders where the data is being copied to.
“Are you saying that it correctly writes to disk when first syncing a file, but fails (as in keeps filling up modified mem. until OOM) when continuing a sync that started already earlier (i.e. the syncthing temp file already exists)?”
Yes, that’s exactly what I am seeing. It appeared to only start having issues when I was in a high % downloaded which makes me wonder that with the constant reloading of St (due to say windows updates, RC updates etc) it becomes fragmented internally rather than at a traditional file level or even corrupted? Just thinking out loud.
I have no clue what that means.
However with the amount of moving parts (internal vs external usb disks, windows updates, AV, restarts, …) this is not debugable like this (no accusation, you said so early on), but also very unlikely to be related to 1.5.0. If you wanted to investigate, what I would check the tools mentioned whether they can provide you with logs of disk access, then disable AV, updates, … and run on internal disk and try to reproduce the behaviour by restarting yourself.
[quote=“terry, post:24, topic:14881”] […] it becomes fragmented internally rather than at a traditional file level or even corrupted? Just thinking out loud. [/quote]
I have no clue what that means.
Like a file gets fragmented and we use defrag to sort it out, I wondered if there was any internal bit fragmentation due to blocks being added in random places. Just an end user thought!!
very unlikely to be related to 1.5.0
My feeling is that this started on 1.4 as that’s when I struggled to sync files, had lockups and at the time the opinion was it was related to USB drives being used and thus, high IO.
So plan today is that I have a partial downloaded tmp file (same file) on the server so i’m pulling that over to the PC. I have restarted St to see if I get modified memory increases at an early stage, but later I will swap to the partially downloaded file and do a comparison.
I operate 4 large Windows filesets with Syncthing and know that issue well.
However, to what I know, it is not primarily a Syncthing issue, but a Windows Issue.
Look for ‘Intelligent Standby List Cleaner’ for a start into the topic. I use this utility on all machines - without, Syncthing (or anything that reads big amounts of data) and current Windows 10 together freeze any of my machines.
I guess/hope that MS developers created an API to avoid that, because I don’t think you can provoke a frozen machine just with a full scan of the OS anti virus tool 
If so, and if the Syncthing developers find the time to learn about the issue, maybe Syncthing can tell Windows not to clog the whole RAM with cached file handles.
Until then, in an ideal world, a copy of the utility should be attached to every Syncthing for Windows download 
