Dual boot shared folders resyncing continuously

Support
1

I have been using ST on a few dual boot systems, Windows 10 and Ubuntu mainly but also a system that is Windows 10 and Mint Debian. Generally thing work pretty well except on my latest setup, when I change OSs (i.e. when I have synced under Linux and then boot Windows 10 and run ST or the other way around) a large number of files show up needing synchronization from the dual boot machine sent to other machines sharing the same folders. I can only check a few of the files before things get straightened out, but these are not the most recently altered files; many have dates of over a year ago. Any idea what I can do to reduce the unnecessary syncing?

Details on the configuration:

Under Windows my computer has a the OS and programs loaded on drive C, shared folders and shared data files are located on a separate NTFS partition of the same physical SSD which appears as drive D. The contents of C:\Users\mike\AppData\Local\Syncthing are:

  • config.xml - local file so I can use Windows syntax for paths
  • cert.pem symbolic link to D:\SyncThing\0SharedAppData\cert.pem
  • csrftokens.txt symbolic link to D:\SyncThing\0SharedAppData\csrftokens.txt
  • https-cert.pem symbolic link to D:\SyncThing\0SharedAppData\https-cert.pem
  • https-key.pem symbolic link to D:\SyncThing\0SharedAppData\https-key.pem
  • index-v0.14.0.db symbolic link to D:\SyncThing\0SharedAppData\index-v0.14.0.db
  • key.pem symbolic link to D:\SyncThing\0SharedAppData\key.pem
  • syncthing.log symbolic link to D:\SyncThing\0SharedAppData\syncthing.log

all these symbolic links are create using a command similar to “mklink cert.pem D:\SyncThing\0SharedAppData\cert.pem” except for the db directory which was created using “mklink /D index-v0.14.0.db D:\SyncThing\0SharedAppData\index-v0.14.0.db”

Under Linux, there is a third partition on the same SSD formatted as EXT4 which is mounted as / for all the system and home directories. The NTFS shared partition is mounted as /mnt/SHARED and the contents of ~/.config/syncthing are once again symbolic links (created with “ln -s”) for all files except config.xml which is a local file to accommodate the Linux syntax for paths.

I create the setup by first installing SyncTrayzor under Windows and allowing it to create and populate the shared folders on the D drive. I reboot to ensure nothing is running, copy the contents of C:\Users\mike\AppData\Local\Syncthing to a non-synced folder on the D drive, delete the local files and generate all the links. I then boot into Linux, add the apt repos, install syncthing, run syncthing once sharing nothing and connecting to nothing. I reboot Linux, delete everything under ~/.config/syncthing and create symbolic links, finally I copy in the Windows config.xml and change the paths to Linux syntax.

Might be worth noting??:

  • The first time I ran the Linux syncthing command it re-synced everything.
  • I do not run either Windows nor Linux syncing by default as I travel a lot and only want to sync when I am not on my mobile hotspot.
  • csrftokens.txt remains a link under Windows but is changed to a local file under Linux; I doubt this is a clue, its just an observation for completeness, as these are session tokens I can’t see that this matters.
  • The NTFS mount for Linux uses “relatime” so that there are no read timestamp updates
2

So the actual files live somewhere on NTFS and are indexed into the database, including their metadata. It’s quite likely that this metadata will look different from within Windows and when mounted on Linux. In the latter case there will be permissions synthesized by Linux, for example. The timestamps are likely to differ either greatly (due to difference in interpretation of the time stamps; local time in Windows and UTC on unixes) or a little due to differences in API (whether precision is seconds, milliseconds, microseconds, or nanoseconds).

So yeah, I’m not surprised that Syncthing on Linux thinks things have changed since they were indexed on Windows and vice versa. Checking “ignore permissions” might help, but there may still be a timestamp difference.

There’s a tool stfileinfo that can be run to see exactly what Syncthing (equivalently) sees about a file. It’s not in the package as a compiled binary, though…

Edit: Here’s a build, where you can grab stfileinfo if you like. If you run it, look at the information under “Lstat”, especially “Mode” and “Time”, where the numerical representation of time is the relevant thing, not necessarily the string which can vary with the system timezone:

$ stfileinfo README.md
File:
  README.md

Lstat:
  Size: 4950 bytes
  Mode: 0644  <-- this
  Time: 2018-09-09 14:20:11.716958554 +0200 CEST
        1536495611.716958554  <-- and that

Blocks:
  Block{0/4950/4185709437/407c28c37c640b8f4d82712434a33e85803708657d1eae99bdadf88faa3d256c}
3

After changing ignorePerms=“false” to ignorePerms=“true” for each shared folder (since I’m doing odd stuff I do not use any normal tools for configuration) it is now down to a remarkably quick update each time I switch.

I do not recall having to do this on previous dual boot systems, and, as I said, it appears a few files still fall through and get “updated” which I will look at some later time, but things are working well enough that I am going to not worry and proceed to rebuilding my workstation after the disk failure.

Thanks

4

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