I am new to Syncthing and run into a problem, were I don’t know whether it is caused by a bug in Syncthing or something else.
I am using Syncthing to copy folders from a Windows 10 machine to a NTFS hard disk mounted on a Raspberry Pi. On the Windows 10 source machine all folders are send only, on the target Raspberry Pi all folders are receive only and use simple file versioning.
Synchronisation works fine for all folders except two: a Firefox and a Thunderbird profile folder. After synchronisation I have notifications on the target Raspberry Pi of locally changed items and a “Revert Local Changes” button appears. These files are either sync-conflict files or their original counterpart, often multiple versions of the same conflict. The number of affected files slowly increases over time.
Clicking on “Revert Local Changes” has only a temporary effect. Nofications about locally changed items start to come in again almost immediately.
I made a fresh setup by removing the folders from Syncthing, then deleting them entirly from the Raspberry Pi and configuring everything again in Syncthing, but nothing changed. At the same time other folders are synchronized without this problem.
Therefore, I can think of no way, that something else than Syncthing itself is responsible for the locally changed items on the target machine.
The only cause of a difference between a file version on the source and on the target machine that I can think of is that during synchronization the files on the source machine were changed by Firefox and Thunderbird (but the problem persistet even if I closed Thunderbird). However, in such a case I would expect Syncthing to simply update that file on the target machine during the next pass.
I found some discussion on this forum about problems with locally changed items and reverting local changes, but none seems to exactly fit to what I am observing.
Generally speaking, “odd” filesystems like NTFS on Linux may not preserve all attributes like we expect – for example, we set a certain set of permissions flags, and the FS claims to allow it, but when we look at the file the next time the permission flags are different because the ones we set weren’t actually representable in NTFS. Normally this isn’t a big problem, we update the permissions as seen and don’t cause a conflict because the content is the same.
The Firefox/Thunderbird profiles are probably databases that are memory mapped files. On Windows that means we can’t determine changes properly (because they don’t generate FS notifications, and Windows doesn’t update the modification timestamp on write). So there’ll be attempts to sync the file where we discover the data is “wrong” (unexpected), forcing a rehash of the file, and then it syncs. Again generally speaking, this won’t necessary cause a copy that is usable because it might be an inconsistent state of a database being updated.
I don’t know exactly how, but I think a combo of the two effects above lead to what you’re seeing.
You can turn off conflicts on the receiving side (maxConflicts=0) to bandage over this behavior. Whether that means your synced profiles are healthy or not is unknown.
A little side track, but still on the topic, I think. I basically do the same, i.e. sync user profiles of Thunderbird and a few web browsers. The general idea here is not to have a usable copy while the program is still open on the other side. However, the goal is to have a usable copy at least after the program has been closed. It is just easier (or lazy, depending on how you view it) to have the folder added and synchronised with Syncthing all the time rather then use some other tools to sync the profiles only when they are offline .
I have just tested it, and this indeed seems to be the case, at least with Thunderbird (and likely other Mozilla-based programs like Firefox, SeaMonkey, Palemoon, etc.).
Thank you for your initial explanation, where you mentioned file permissions, which put me on the right track! I was able to solve the problem by checking the option to ignore permissions in the Advanced tab of the Edit Folder dialog for the folders on the target Raspberry Pi. (This was sufficient. It was not necessary to check this option on the source Windows 10 machine.)
Could it be that the problem was not specifically related to NTFS, but to the fact that the source files were assigned to a specific user of the source machine and not to an admin account, a situation that cannot be reproduced on the target machine that has no equivalent user account?
.