Remediation mode prevents the reconciliation scan which readiness depends upon,
so the application never becomes ready while the modification-time limit is set.
Since the result processor began waiting for readiness, nothing was applied in
that mode at all, not even changes older than the limit, which is what the mode
exists for. Result application no longer requires readiness while the limit is
configured, but it does require a usable local database, because a change applied
while a fetch has reset the database cannot gather its chunks and is dropped.
The limit itself is still enforced for every change.
A scheduled fetch also no longer offers Simple Fetch in this mode. Simple Fetch
reconciles the Vault with the local database after fetching, past the check which
refuses that scan, so it could store the current files or write changes newer than
the limit. The detailed flow states the restriction and offers to clear it first.
Use typed Commonlib outcomes to guide Fetch and Rebuild without treating a new remote as a failed read. Preserve automatic synchronisation choices when scheduled initialisation is cancelled.
Simple Fetch asked the same mode and deletion choices again after a failed or interrupted pending Fetch All run.
This stores the selected quick-flow choices in local small config until the operation completes, is cancelled, or is finalised.
- Database fetching (a.k.a. Reset Synchronisation on This Device) on the initialisation now supports streaming and is faster (CouchDB only)
- The database fetching process has been streamlined, and database operations are now suspended until it has been completed
- The initial synchronisation process has been simplified, making it easier to synchronise files with the remote server
- We can select the remote database to fetch from during the initialisation, when there are multiple remote databases configured (e.g. multiple CouchDBs or S3 remotes)
Kim Jansheden