I appreciate this is a nice use-case - but if I had a synced folder on a removable drive, and I moved that drive between two systems which were both configured to sync that folder (as the same folder ID), am I right in thinking that it Should Just Work?
e.g. When moving the drive from System 1 to System 2, and scanning the folder:
Data on the drive which System 2 was previously unaware of will already be in the cluster’s database, and so will be left untouched on the drive;
Data which has been deleted off the drive since System 2 last saw it will already be in the cluster’s database as deleted, so System 2 won’t want to restore it back into place.
Is my thinking right, or is there a danger of data loss when doing this?
Changes that happened while the drive were away will look like new local changes and cause conflicts I think, likewise if you have things like files that were deleted but then came back while the disk was away, will now look like new deletes and get deleted elsewhere again… The details depend on … details, but I think “Should Just Work” is not the correct characterisation.
Thanks; in this particular case, any changes on the drive would have been made whilst that drive was syncing under System 1 - so the cluster would already be aware of these changes on that drive, albeit from a different device.
Does that change the “Should Just Work™” answer at all?
I am not an expert, but this sounds a little bit risky for myself.
How about running a separate instance of Syncthing directly from the removable drive, using relative paths to sync only that folder? This way there will be only one config and database to take care of. I have been doing so with several folders located on a portable USB stick for months with 0 problems.
the disk is fully up to date with the global status at the point you disconnect it, and that
no changes happen anywhere else in the cluster until it’s connected at system 2, and
no changes happen anywhere until system 2 has done whatever it needs to become in sync again,
then I can’t immediately think of something that will go wrong. If you can’t guarantee that the rest of the cluster is “frozen” during this operation then you’ll end up with system 2 seeing one modification happen on disk and another from the network and have a conflict that needs resolving – potentially being resolved in the wrong direction.
Frankly though, the portable setup is the better one for this case.