Locally changed items in folder

Support
#1

I am experiencing a problem essentially identical to this thread. There was no real resolution there, except to suggest syncthing might have been the wrong tool.

This is on the same ARM7 device I talked about earlier that I had been having database corruption issues with. That problem was solved, but with a very large folder synchronized I started seeing large numbers of “locally changed items” appearing. The folder has 15k items taking 96GiB of space. I have synchronized it several times, each time there are about 30% of the files that later show as locally modified.

Originator is Windows 10, with ST version 1.13.1. Receiver is Linux ARM7 with ST version 1.11.1. Checking ignore permissions on sender and receiver did not have any significant effect.

This is on a customer’s site and my time was limited today, so I have not yet investigated in depth. On one file, though, I verified that the md5sum checksum on both sender and receiver was the same, as were modification and access timestamps the same (to the second). Creation timestamps were not the same, but they do not appear to be the same for any files that ST sends. What else could ST be using to determine if the files were changed? Is there a way to get ST to tell you why it has decided a file has been changed?

#2

What file system are the files located on?

Just for the record, I have also recently experienced some strange issues with “Local Additions”, even though the files appeared to be exactly the same. Basically, the situation was like this. If the folder was set to “Send & Receive”, then all was “Up to Date”. Changing it to “Receive Only” immediately triggered “Local Additions”. However, setting it back to “Send & Receive” cleared those “Local Additions” again. I am still not sure what the culprit was. Everything was under Windows and located on NTFS though. I have also failed to reproduce the problem in my test environment so far, so there is that :confused:.

#3

Both the source and destination filesystems are NTFS, however the destination OS is Linux which is mounting the NTFS drive using the Paragon driver.

If I had to venture a guess, the problem has to do with timestamp resolution. Perhaps in the way either the OS or syncthing is rounding the timestamp to the nearest second (or nearest whatever it is that ST uses internally for timestamps). I will know more when I can spend more time on this. Another possibility is time zone and the way daylight savings works between OSes.

Changing to send/receive is not really a solution. What happens when it’s sent/receive is on the receiving side whatever difference it thinks there is in the file is then just being transmitted back to the other side which is incorporating that change. This is not a solution, and is in fact dangerous. What if it was filesystem corruption, then would you want those changes propagated back? The answer is to figure out why syncthing thinks the file is different and fix that. Either something on the receiving side is touching the file, or there is an issue in syncthing that needs addressing. Two of the people having this issue had one side of the transfer using Linux. You had Windows on both sides… were they the same version of Windows?

#4

Yeah, that is one possibility, although in my understanding, Syncthing does not care for time zones and such, as long as the actual modtimes have not changed.

#5

Yeah, that is one possibility, although in my understanding, Syncthing does not care for time zones and such, as long as the actual modtimes have not changed.

Of course, this is situation dependent.

Our case was actually a little bit more complicated. Basically, there are three computers. All run the same version of Windows 10 Enterprise 2019 LTSC with NTFS partitions using all default settings, with the exception of the NTFS compression being enabled.

All was “Up-to-Date” initially in the following configuration.

  • Device A (Send & Receive)
  • Device B (Send & Receive)
  • Device C (Receive Only)

Then we tried setting A to “Receive Only”, which resulted in tons of “Local Additions”, even though the files themselves have not changed. After “reverting” them, we switched back to “Send & Receive”, and everything was marked “Up to Date” again.

Next, we applied the same procedure to Device B. The files were also marked “Local Additions” there. “Reverting” changes caused many of them to be re-downloaded from the other devices.

Now, all the devices are back to their initial configuration, i.e. two “Send & Receive”, and one “Receive Only”, and everything is “Up to Date” and syncing great, but I still have no idea why those files were marked “Local Additions” in the first place.

#6

It looks at size, modification time and optionally permissions to detect changes. You can query GET /rest/db/file — Syncthing v1 documentation on the device showing the locally changed items (for instructions: [ How To ] call the REST API from Windows PowerShell).

Possibly that is a filesystem following a pattern Syncthing dislikes: It might store high-precision timestamps in memory when Syncthing sets the modification time, and once that’s erased (restart) it lost that information and shows lower-precision timestamps. Which Syncthing detects as a chang.