7c07610ab2
We've always, since the introduction of conflicts, had the policy that
deletes lose against any other change, for safety's sake. This is a
problem, however, because it means the sort order of versions is not a
total order.
That is, given two versions `A` and `B` that are currently in conflict,
we will sort them in a given order (let's say `A, B`, so `A < B` for
ordering purposes: we say "A wins over B" or "A is newer than B") and
consider the first in the list the winner. The loser (who has `B` on
disk) will process the conflict at some point and move the file to a
conflict copy and announce `A'` as the resolved conflict. The winner
(with `A` on disk) doesn't do anything.
However, if `A` is deleted the ordering changes. We still have `A < B`
and, of course, `Adel < A` (this is not even a conflict, just linear
order). In most sane systems this would imply the ordering `Adel < A <
B`, however in our case we in fact have `B < Adel` because any version
wins over a deleted one, so there is no logical ordering at all of the
files at this point. `Adel < A < B < Adel ???` In practice the deleted
version may end up at the head or the tail of the list, depending on the
order we do the compares.
Hence, at this point, "whatever" happens and it's not guaranteed to make
any sense. 😬
I propose that we resolve this my simply letting deletes be versions
like anything else and maintain a total ordering based on just version
vectors with the existing tie breakers like always. That means a delete
can win in a conflict situation, and the result should be that the file
is moved to a conflict copy on the losing device. I think this retains
the data safety to almost the same degree as previously, while removing
probably an entire class of strange out of sync bugs...
---
(A potential wrinkle here is that, ideally, we wouldn't even create the
conflict copy when the delete and the losing version represent the same
data -- same as when we handle normal modification conflicts. However,
the deleted FileInfo doesn't carry any information on what the contents
were, so we can't do that right now. A possible future extension would
be to carry the block list hash of the deleted data in the deleted
FileInfo and use that for this purpose, but I don't want to complicate
this PR with that. The block list hash itself also isn't a
protocol-defined thing at the moment, it's something implementation
dependent that we just use locally.)
1.8 KiB
Major changes in 2.0
-
Database backend switched from LevelDB to SQLite. There is a migration on first launch which can be lengthy for larger setups. The new database is easier to understand and maintain and, hopefully, less buggy.
-
Deleted items are no longer kept forever in the database, instead they are forgotten after six months. If your use case require deletes to take effect after more than a six month delay, set the
--db-delete-retention-intervalcommand line option or corresponding environment variable to zero, or a longer time interval of your choosing. -
Modernised command line options parsing. Old single-dash long options are no longer supported, e.g.
-homemust be given as--home. Some options have been renamed, others have become subcommands. All serve options are now also accepted as environment variables. Seesyncthing --helpandsyncthing serve --helpfor details. -
Rolling hash detection of shifted data is no longer supported as this effectively never helped. Instead, scanning and syncing is faster and more efficient without it.
-
A "default folder" is no longer created on first startup.
-
Multiple connections are now used by default between v2 devices. The new default value is to use three connections: one for index metadata and two for data exchange.
-
The following platforms unfortunately no longer get prebuilt binaries for download at syncthing.net and on GitHub, due to complexities related to cross compilation with SQLite:
- dragonfly/amd64
- illumos/amd64 and solaris/amd64
- linux/ppc64
- netbsd/*
- openbsd/386 and openbsd/arm
- windows/arm
-
The handling of conflict resolution involving deleted files has changed. A delete can now be the winning outcome of conflict resolution, resulting in the deleted file being moved to a conflict copy.