A lot of "revert local changes" after a shutdown of Kobo

Support
1

Dear all,

I am running syncthing on my Kobo Elipsa with KoReader, and find that, after a shutdown of device, there are a lot of “revert local changes”. After some search, I tried to modify modTimeWindowS to be 2, but the issue persists.

Here is an example (I have tried to clear some sensitive IDs) of

the output of `syncthing cli debug file` 
{
  "availability": [
    "AAAAAAA-*",
    "BBBBBBB-*",
    "CCCCCCC-*",
    "DDDDDDD-*",
    "EEEEEEE-*"
  ],
  "global": {
    "deleted": false,
    "ignored": false,
    "inodeChange": "1970-01-01T01:00:00+01:00",
    "invalid": false,
    "localFlags": 0,
    "modified": "2020-07-05T14:22:42+02:00",
    "modifiedBy": "AAAAAAA",
    "mustRescan": false,
    "name": "valuations.tm",
    "noPermissions": false,
    "numBlocks": 1,
    "permissions": "0644",
    "platform": {
      "darwin": null,
      "freebsd": null,
      "linux": null,
      "netbsd": null,
      "unix": null,
      "windows": null
    },
    "sequence": 34285,
    "size": 11303,
    "type": "FILE_INFO_TYPE_FILE",
    "version": [
      "ZZZZZZZ:1658028806",
      "EHEAUO7:2",
      "JRZLOMD:1",
      "LPNSX6U:1",
      "AAAAAAA:1658037267"
    ]
  },
  "globalVersions": "{{Version:{[{ZZZZZZZ 1674668862} {EHEAUO7 2} {JRZLOMD 1} {LPNSX6U 1} {AAAAAAA 1658037267}]}, Deleted:false, Devices:{}, Invalid:{7777777}}, {Version:{[{ZZZZZZZ 1658028806} {EHEAUO7 2} {JRZLOMD 1} {LPNSX6U 1} {AAAAAAA 1658037267}]}, Deleted:false, Devices:{AAAAAAA, BBBBBBB, CCCCCCC, DDDDDDD, EEEEEEE}, Invalid:{}}}",
  "local": {
    "deleted": false,
    "ignored": false,
    "inodeChange": "2023-01-20T07:25:19+01:00",
    "invalid": true,
    "localFlags": 8,
    "modified": "2020-07-05T13:22:42+02:00",
    "modifiedBy": "ZZZZZZZ",
    "mustRescan": false,
    "name": "valuations.tm",
    "noPermissions": true,
    "numBlocks": 1,
    "platform": {
      "darwin": null,
      "freebsd": null,
      "linux": null,
      "netbsd": null,
      "unix": null,
      "windows": null
    },
    "sequence": 91818,
    "size": 11303,
    "type": "FILE_INFO_TYPE_FILE",
    "version": [
      "ZZZZZZZ:1674668862",
      "EHEAUO7:2",
      "JRZLOMD:1",
      "LPNSX6U:1",
      "AAAAAAA:1658037267"
    ]
  },
  "mtime": {
    "err": null,
    "value": {
      "real": "0001-01-01T00:00:00Z",
      "virtual": "0001-01-01T00:00:00Z"
    }
  }
}

The output of syncthing --version:

syncthing v1.23.0 "Fermium Flea" (go1.19.4 linux-arm) teamcity@build.syncthing.net 2023-01-02 03:45:30 UTC

I wonder how to resolve this issue? It looks like that the only difference is the inodeChange, but I have already opted for “ignore permissions”. Thanks.

2

This happens as long as the Kobo Reader is powered off from KOReader.

3

The timestamps are precisely an hour different, which to me sounds like a time zone confusion. Perhaps the system uses a FAT filesystem (which uses local time in timestamps) and the timezone changed, or perhaps it uses some funky filesystem wrapper that caches times while it’s running but then they change when it restarts. It’s not precisely a normal computer…

4

It is FAT32, but the timezone is not changed. To inform, I am under CET (UTC+1), thus there are several potential reasons for an hour:

  1. UTC vs local time;
  2. DST vs normal time.
5

Is this related: timezone - VFAT, Linux: Invalid file timestamps shown after a reboot - Unix & Linux Stack Exchange

It looks like a generic issue for FAT filesystems under Linux. I wonder whether there are known solutions?

6

Fascinating. Doing timestamps-without-timezone is up there somewhere together with the null pointer in terms of billion dollar mistakes.

7

Any option of Syncthing for alternative timestamps available on FAT filesystems?

8

Maybe a modtime window of 5400 (one and a half hour)… (Or maybe more if you’re in a timezone further away from UTC)

9

Is there a specific reason why the folder needs to be set to “Receive Only”?

If not, then you could just set it to “Send & Receive” and let Syncthing change the timestamps to what the FAT uses…unless you really need the exact mtime preserved, of course. If you do that, Syncthing will simply update the mtime on the other side, i.e. it should be instant with no actual file data being transferred.

10

I guess that this does not work well, as it does not synchronize the changes within an hour and half, say.

Is it possible to revert local changes from cli? Currently, I revert them by allowing remote visits of Web GUI (the browser on Kobo is too rudiment), but this is cumbersome and only doable when I have another device in the same local network. Due to the security issue, I only do this in trustable places, thus very inconvenient.

11

The modtime window has no effect on how fast changes are synced (in either direction). It only affects how different the timestamp on the file needs to be from the timestamp in the database for it to be considered changed when we look at it locally.

12

Thanks. Then it might be OK to set it to 24 hours, so that I would not be concerned in anywhere on the world.

13

There is a risk that if it is changed locally for whatever reason, it would propagate. A priori, I do not trust Kobo — in terms of data loss or whatever “features” that would lead to such a surprise.

14

Yeah, understood. I do the same for Android which I also don’t trust while I still need to have access to the files, so I set everything to “Receive Only” and only a few selected folders to “Send & Receive”.

15

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