This release performs a database schema migration, and adds the
BlockPullOrder, DisableFsync and MaxConcurrentWrites folder
options to the configuration schema.
The LocalChangeDetected event no longer has the action set to
added for new files, instead showing modified for all local file
changes.
Bugfixes
#3876: Removing and re-adding a folder may cause data loss
Just wanted to impart a bit of positivity into the world: I’ve been fighting (again…) with a NAS with limited RAM and many files that had got itself way out of sync with a peer (I suspect someone had moved a big bunch o’ files on one machine); running v1.5.0, Syncthing would get killed after about 12 hours, whilst it was Preparing to Sync a large folder.
I applied all the tweaks I could find to reduce the memory, and was in the middle of investigating further, but saw v1.6.0 was on the horizon, and might help my situation.
Having let the system upgrade to v1.6.0 then v1.6.1, I’m pleased to report that 19 hours later, Syncthing is still running very happily thankyouverymuch. It appears to have got through whatever was causing the high RAM footprint, and has now got itself into an ‘Up to Date’ state.
I was going to post that there were still some files missing from one side - but I see that there’s a whole load of index exchanges going on - so I guess it’s still getting its house in order (indeed, the Global State does not match between devices too). But this is much further than it got under v1.5.0 - so thankyou thankyou thankyou yet again!
Obviously I don’t know the innards and how easy this is to reliably detect, but: given there’s a whole load of index exchanges happening, surely the ‘Up to Date’ status is misleading? Is there an argument for setting the status to ‘Receiving Index Updates’ on the receipt of an index update, until either a ‘Preparing to Sync’ or ‘Up to Date’, etc status is triggered?
