

I guess the old exe stays around somewhere, so if you run from the command line, pay attention to which one you’re starting, maybe based on the file modification date.
#Syncthing stop sync update
That may trigger an update of your configuration file so it’s no longer usable from the older version. When it runs, a new syncthing.exe is downloaded when updates are available. The thing is, SyncTrayzor comes bundled with a syncthing.exe.

21:20:30 INFO: syncthing v1.18.1 “Fermium Flea” (go1.16.6 windows-amd64) 12:41:57 UTCĪnd for what reason do you need to run it from the command line then? Or did you maybe reinstall without removing your user settings as well? 21:20:30 INFO: Log output saved to file “C:\Users.…\Syncthing\syncthing.log” If this is expected, use -allow-newer-config to override. 21:20:30 WARNING: Failed to initialize config: config file version (37) is newer than supported version (35). 21:20:29 INFO: Log output saved to file “C:\Users.…\Syncthing\syncthing.log” What should I do? BTW I hid where I placed the Syncthing for anonimity so you might see “C:\Users.…\Syncthing\syncthing.log” This showed on the Syncthing Console when I started running it at my laptop. Contrary to Audrius I think this might be a help-wanted but then we at least need to clarify how it should work.Hello I’m a newbie at programming so please be patient with me.
#Syncthing stop sync plus
If we end up with something advanced (at least space for the file we're going to sync, plus 50% overhead, but at least 10 MiB, unless that's more than 10% of the disk space, but only for folders larger than x.) this needs to be understandable to the user.

#Syncthing stop sync full
whatever method we choose should mean we don't fill the disk, which would not be the case by for example just going with a 95% full limit as we might still try to sync a file that's 6% of the total disk size. User configurable, possibly, but the less we need to ask for the better. That'd probably be fairly safe (barring the multiple-files-being-synced-in-paralell thing that may need handling) but also means we wouldn't be syncing stuff that we otherwise could have been.Ībsolute values are obviously no good (8 GB free would be a good warning limit on my photo folder, but not on a phone), percentages likewise (5% of my data pool is still 900 GB). We could do as above (check before each file) but stop completely once it doesn't fit. We'll try smaller files in that case (as we always try to sync the next file in the list if one file fails for whatever reason), so we might still get very close to full filesystem - basically as close as the smallest file we have in the repo. We could try to do the check just before copying a file, possibly, and skipping it if the amount of free space looks marginal (I recall trying something like this in a branch ages ago, I wonder what happened to that.). But that could mean we want 100 GB of free space just to update a text file. Assuming we can detect the amount of space left on the device, what would we aim for as a limit? We may create temporary copies of (by default) up to 16 files when synchronizing them, so we would need to reserve space for at least copies of the 16 largest files in the repo to be sure a sync is going to work.
