Hi,
I am experiencing a problem similar to this; the commonalities are the presence of storage over a nas path, Windows Server2008 on the destination and Syncthing version above the v0.12.3
I have a setup where a machine with a folder master syncronize over internet to a ‘slave’ machine whose folder path is on a NAS path (\mynas\Docs…).
For example, if I add a byte to a file on the source machine (using a simple dos command like type onebytefile.txt 1 >>destination.txt) and trigger a rescan, on the destination machine I get the file with the right content but the file time is a few seconds ahead from the original time and on the Syncthing page in the source machine appears the conflict with the ‘Override Changes’ button.
If on the destination machine I use Syncthing v0.12.3 or put the folder over a local disk the problem does not appears.
I think it’s because some filesystems have very inacurate mtime resolution, and your nas seems to be one of them. Yet it shouldn’t generate conflicts if the content is the same.
Same problem happens also if the share is on a Microsoft OS.
I did not think this is a problematic mtime resolution.
As stated by domonoky here I think the issue is not on the filesystem side but in a change of Syncting’s source code: all versions above the 0.12.3 are producing those bogus conflict files where 0.12.3 not.
Moreover on the destination node I am sure that files are untouched by anything (no antivirus, indexing services or other sort of software).
Well as I’ve pointed out in the ticket, there doesn’t seem to be anything related to conflicts between the versions. The guy who raised the original ticket said he’s going to do a binary search on which commit is to blame. If you beat him to it, I promise we’ll look into it.
Having some free time, I conducted some tests with ProcessMonitor using Syncthing v0.12.3, v0.12.4 AND v0.12.19.
May be that between the v0.12.3 and following releases there was been a change in some thirdy party library you link with?
I included a spreadsheet with the calls issued to the OS by Syncthing when monitoring changes to a file named incr.txt.
In the sheets st12.19-1, st12.19-2, st12.4-1 there are two traces for Syncthing v0.12.19 and one for the v0.12.4.
In the sheets st12.3-1 and st12.3-2 there are two traces for for Syncthing v0.12.3.
For version 0.12.4 and above the pattern of calls is the same but it is different from v0.12.3 when the program first retrieves some info on ~syncthing~incr.txt.tmp. This give me a suspect to changes on an underlying library.
Continuing to look at the traces, you can see the call to SetBasicInformationFile on ~syncthing~incr.txt.tmp to set the LastWriteTime followed, some row after, by a call to QueryBasicInformationFile on same file that retrieves a wrong LastWriteTime for Syncthing v0.12.4 (and above): I think this lead st to create conflict files; Syncthing v0.12.3 instead retrieves the right time set in the previous SetBasicInformationFile call, not going to create conflict files.
So if you want to help, the best way to find the reason is to do a git bisect between the two releases (one that works and one that doesn’t) and find which commit introduces the problem.
Tracing API calls doesn’t mean much, as it doesn’t translate into exact code changes.
Libraries are not used for conflicts, etc, so I doubt it’s a library.
Audrius, I think have made a change inadvertently to source and am unable to revert.
I see a ‘Merge remote -tracking branch…’ made by myself in the history.
I was using the GitHub application but the revert commit does not work for me.
How can I correct this mistake?
Please forgive me, being new to Git, I thought of working in read-only mode not being member of the project…
Luckily I don’t have write rights so no changes was applied on the remote repository.
Only the GiHub application showed me the changes based on my local repository state but was -lukily- unable to apply them on the remote.
Being new to Git, I was in search to make a fast comparison between the v0.12.3 and v0.12.4 source code versions.
D:\src\github.com\syncthing\syncthing [master +1 ~0 -0 !]> git bisect bad v0.12.4
You need to start by "git bisect start"
Do you want me to do it for you [Y/n]? y
D:\src\github.com\syncthing\syncthing [master +1 ~0 -0 !]> git bisect good v0.12.3
Bisecting: 16 revisions left to test after this (roughly 4 steps)
.
.
D:\src\github.com\syncthing\syncthing [(6ff0276...)|BISECTING +1 ~0 -0 !]> git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[d46f2676634f0d64f5866e5599d20112ec225413] Handle sparse files (fixes #245)
D:\src\github.com\syncthing\syncthing [(d46f267...)|BISECTING +1 ~0 -0 !]> git bisect bad
d46f2676634f0d64f5866e5599d20112ec225413 is the first bad commit
commit d46f2676634f0d64f5866e5599d20112ec225413
Author: Jakob Borg <jakob@nym.se>
Date: Sat Nov 21 16:30:53 2015 +0100
Handle sparse files (fixes #245)
:040000 040000 7cabfed8c66fcef21b9dc0e2b4a9e166c91e8528 4b5b65777230fd09e2106f103a20f6cbe0819b1a M lib
:040000 040000 c834417db113a4f6be5009c6e3ff2a48d0fa9337 a780f537991cb77e1907eb1d07f2daf9279287a5 M test
D:\src\github.com\syncthing\syncthing [(d46f267...)|BISECTING +1 ~0 -0 !]>
This commit starts to create sync conflicts when target folder is over a network share (like \servername\volume\folder)
I see that the official Syncthing application is compiled with go1.6rc1; not finding same release on the GO download page, I instead used the go1.6 final.
I am new to Git and GO, but can confirm that using git bisect between v0.12.3 and v0.12.4, cleaning-compiling-testing the resulting source from the git bisect good/git bisect bad, finally reached that commit where the problem appears.
So I think I know what the problem might be, I think it’s todo with how NFS and SMB handles sparse files. Do you have an environment I could run some tests in? I assume the clients using the network storage are windows?
Yes, if you want, let me known what are your needs. My environment is made only of Windows machines.
I discovered initially the problem putting the destination folder on a SMB share exposed by a QNAP NAS, however the problem arises also over a share exposed by a windows virtual machine.
Note that my case has not to do with sparse file but instead with simple text files made of only few characters.