Syncthing across timezones

Support
1

The wifey took one of my laptops (say L1) abroad (+10.5 hours time difference). After a week of hiatus, she turned it on today.

I noticed that some 3 GB of photos I had cleared from my other laptop (L2) and Phone were slowly getting downloaded by Syncthing!

I’m wondering if Syncthing thought those files were new as the laptop L1 was in a timezone ahead of timezone of L2. Is Syncthing designed to function smoothly across timezones?

I asked her to immediately shutdown Syncthing to stop further sync, but how to clear this mess now?

2

Syncthing isn’t affected by time zones, all times re in UTC internally. Most likely those photos were changed on the other laptop while it was disconnected, and they were then synced back over the deletes due to that change.

3

Thanks for your reply.

I highly doubt 3+ GB worth of photos were changed in the laptop :slight_smile:

How do you think I can recover from this? Should I let the files sync anyway, and then perform the deletes again?

4

You can set it to send only and then hit “override”. Note that this rejects all remote changes that have not yet been synced.

5

I got that laptop back, and am just letting things sync again, so I can get some stats. Here’s what I see from the http://localhost:8384/rest/db/file REST api call for one of the files that I had deleted.

Legend:

SVMGIUF: Phone
OZ5QQ2B: Lenovo Laptop (where REST api was called)
GT2TZ34: Asus Laptop   (Taken abroad)

Output of the REST api call (as the file was getting re-synced)

{
   "local" : {
      "modified" : "2017-08-27T18:18:29.276039376-04:00",
      "size" : 0,
      "version" : [
         "OZ5QQ2B:1",
         "SVMGIUF:1"
      ],
      "noPermissions" : false,
      "name" : "DCIM/Camera/IMG_20170827_181828.jpg",
      "deleted" : true,
      "permissions" : "0",
      "sequence" : 36822,
      "type" : 0,
      "invalid" : false,
      "numBlocks" : 0
   },
   "global" : {
      "sequence" : 9219,
      "modified" : "2017-08-27T18:18:29.2760393-04:00",
      "size" : 3692585,
      "version" : [
         "GT2TZ34:1",
         "SVMGIUF:1"
      ],
      "noPermissions" : false,
      "deleted" : false,
      "name" : "DCIM/Camera/IMG_20170827_181828.jpg",
      "permissions" : "0644",
      "type" : 0,
      "invalid" : false,
      "numBlocks" : 29
   },
   "availability" : [
      {
         "fromTemporary" : false,
         "id" : "GT2TZ34-*******-*******-*******-*******-*******-*******-*******"
      }
   ]
}

As you can see "deleted" : true in the local, but "deleted" : false in the global, and the file was getting synced up.

After sync was completed, here is the output of the REST api call.

{
   "local" : {
      "permissions" : "0644",
      "deleted" : false,
      "invalid" : false,
      "name" : "DCIM/Camera/IMG_20170827_181828.jpg",
      "sequence" : 44628,
      "type" : 0,
      "noPermissions" : false,
      "modified" : "2017-08-27T18:18:29.2760393-04:00",
      "version" : [
         "GT2TZ34:1",
         "SVMGIUF:1"
      ],
      "size" : 3692585,
      "numBlocks" : 29
   },
   "availability" : [
      {
         "id" : "SVMGIUF-*******-*******-*******-*******-*******-*******-*******",
         "fromTemporary" : false
      },
      {
         "fromTemporary" : false,
         "id" : "GT2TZ34-*******-*******-*******-*******-*******-*******-*******"
      }
   ],
   "global" : {
      "permissions" : "0644",
      "deleted" : false,
      "name" : "DCIM/Camera/IMG_20170827_181828.jpg",
      "invalid" : false,
      "sequence" : 44628,
      "type" : 0,
      "modified" : "2017-08-27T18:18:29.2760393-04:00",
      "noPermissions" : false,
      "size" : 3692585,
      "version" : [
         "GT2TZ34:1",
         "SVMGIUF:1"
      ],
      "numBlocks" : 29
   }
}

I now removed the file on Lenovo, and ran the REST api call again.

{
   "local" : {
      "type" : 0,
      "noPermissions" : false,
      "invalid" : false,
      "name" : "DCIM/Camera/IMG_20170827_181828.jpg",
      "modified" : "2017-08-27T18:18:29.2760393-04:00",
      "deleted" : true,
      "numBlocks" : 0,
      "size" : 0,
      "permissions" : "0",
      "sequence" : 44951,
      "version" : [
         "GT2TZ34:1",
         "OZ5QQ2B:1",
         "SVMGIUF:1"
      ]
   },
   "availability" : [
      {
         "id" : "GT2TZ34-*******-*******-*******-*******-*******-*******-*******",
         "fromTemporary" : false
      }
   ],
   "global" : {
      "numBlocks" : 0,
      "deleted" : true,
      "permissions" : "0",
      "size" : 0,
      "version" : [
         "GT2TZ34:1",
         "OZ5QQ2B:1",
         "SVMGIUF:1"
      ],
      "sequence" : 14966,
      "type" : 0,
      "noPermissions" : false,
      "invalid" : false,
      "name" : "DCIM/Camera/IMG_20170827_181828.jpg",
      "modified" : "2017-08-27T18:18:29.2760393-04:00"
   }
}
6

And what’s the issue here?

1 Like
7

Issue is what is mentioned in the very first post.

To summarize, Syncthing considered a bunch of files as modified and started transferring them when they were actually deleted from another machine. @calmh thought that the files were actually changed, which I highly suspect. The very first output above is of REST API call was when one of these files that was actually deleted was being re-synced. I thought it might provide some insight to why this might have occurred.

8

The version on your laptop was modified once on the Phone (created there, maybe?), and once on the Laptop (the delete, presumably):

The one on the other side was modified once on the Phone (which is why I guess that’s the origin) and and once on the laptop:

This is a conflict, since it’s two branches away from the origin in two different directions - one is a modify, the other is a delete. In conflicts between modifications and deletes we let the modification win, in order to preserve data.

9

Thank you for the explanation.

How does Syncthing determine which is the latest change? Is it just on the value of the modified field?

10

In terms of “version” : [ “GT2TZ34:1”, “SVMGIUF:1” ], the one with the highest version wins, given it’s not a conflict. If you care more about what this is then: https://en.wikipedia.org/wiki/Vector_clock

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.