Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing and re-adding a folder may cause data loss #3876

calmh opened this issue Jan 5, 2017 · 3 comments


None yet
3 participants
Copy link

commented Jan 5, 2017

Removing and re-adding a folder causes a reset of the index for that folder and a rescan. Consider the following scenario, with two devices A and B:

  • A and B are in sync
  • A and B are disconnected
  • A changes a couple of files, version vector gets bumped, let's say {A:42, B:36}
  • A removes and re-adds the folder
  • A rescans and assigns new version vectors with {A:1} to everything
  • A and B connect
  • B's older file will have a version vector like {A:40, B: 36}
  • B's older files overwrite A's newer files (it's not a conflict)

Maybe not a super common scenario, but a folder can be removed by mistake and re-added, or because it's moved on disk, or for many other reasons.

Idea: should the short ID in the version vector not be based on our device ID, but instead a random ID assigned to the folder, e.g., our delta index ID?

@calmh calmh added the enhancement label Feb 7, 2017

@calmh calmh added this to the Unplanned (Contributions Welcome) milestone Feb 7, 2017


This comment has been minimized.

Copy link

commented Feb 16, 2017

I was about to submit a bug report about this, then read this issue. I ran into this very thing except in my case, I was moving files on "A", then the disk holding "B" failed (the syncthing config on both hosts was still intact.) So, I removed the folder on B's syncthing and readded it (B now contained partial contents restored), and the results can only be described as pandemonium... after an initial bit of resyncing, moving a file on B would sometimes result in the file instantly being deleted or moved to "sync-conflict", presumably because A's history last saw that file in that state. Thinking about it, it is hard to figure out what exactly should happen in cases like this, but "WTF" behavior is probably not the best. Even a workaround that would give you a warning at some point (maybe at the point there is a suspect folder added) would be preferable.


This comment has been minimized.

Copy link

commented May 9, 2017

What about just changing the version vector from:
current ) monotonically increasing from one
proposed ) unix timestamp based on when it was modified (always increasing as well but later time will never be less than anything done in past even if client is reset or forgets its config)

Or is this one of those things that "fixes something only to break a bunch of other things". I'm guessing that's the case since no ones has mentioned such a simple solution.


This comment has been minimized.

Copy link
Member Author

commented May 9, 2017

@calmh calmh removed this from the Unplanned (Contributions Welcome) milestone Feb 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.