Well no, obviously I am trying to provide logs and infos here how this all happened. I want to know that sycnthing is programmed in a robust way, thats why I am trying to find out whats happening here. I still dont know where to find all the logs from the senders machine inside a single file or something.
I turned on debugging, and I re-created the shared file objects on the sender side, and I am adding it on the remote side now, as you suggested. thats all I can do, is it not?
thanks.
The remote side has finished scanning, and now network traffic is taking place. The remote side is suddenly lacking 1.33gbytes. Will report back how this evolves.
The number of files was over 80something and not only 40something.
First things first:
Your debugging and reporting is very appreciated - that’s how we can get aware of bugs and get rid of them. Especially on windows, as none of the core devs runs Syncthing on windows a lot.
Not meaning to be flippant: I like getting straight answers too, makes debugging easier and faster. Means focus on what I ask. If you want to provide more info, that’s obviously appreciated, but secondary.
How are you running Syncthing? The logs probably go to the same directory where your config is. Unless it’s SyncTrayzor, then it shows you the logs directly in the program (no idea where it saves it).
Simple vanilla syncthing.exe from your .zip file. no wrappers or something. will check the directory once it finished syncing. Can we derive anything at all from this second attempt actually? maybe only which files were eventually transfered this time, that were still missing and not present on the remote side. but maybe not really anything about why there was a mismatch in indexes?
Interesting thing for me to see is, on the senders side, on the lower right side, the remote machine state:
missing files, it currently lists those photograph files, and at the very end of the whole list, there is my test txt file just the same:
_zzzzztest\test-11111.txt
althought it has previously transfered that file to the remote side and was also present in on the remote machine, I have observed and seen the file on my remote access (teamviewer etc…) on the machine.
btw, about log files, I dont see logs in the program directory of syncthing where the .exe binary resides. But the logs seem to be in the same place as the database file, in the appdata path on windows machines.
AppData\Local\Syncthing\
there is the syncthing.log and syncthing.0.log
how do I share these files safely later on, especially with privacy and file/folder/machine names etc…?
While it’s still “in flux”, i.e. comparing files, there’s not much significance. I think I know what’s happening (single file being reported as changed multiple times in a single scan), I just don’t know why. And your logs could help understand and thus prevent that. v1.6.0 has changes so it can handle multiple update at once without producing these errors, but it would still be good to know why it happens in the first place (it shouldn’t). And maybe that’s not the problem at all here.
So essentially all I need, is for the same problem to occur again, then I need the logs plus names of the files which are not transferred.
You can again send it to me by private message. Or email me download links if you prefer.
okay now all of a sudden the receiver took somehow a shortcut, and went from leftover some few hundred megabytes to be fetched, to complete.
both sides and everywhere no on the sender and the receiver, show green sates and fully in sync.
on the receivers side the total traffic was still: Download Rate 0 B/s (1,04 GiB
I can stop both sides now and collect the logs on the senders side and send them to you or anything else? I think the stuff is now really in sync. Will check on both machines with the file explorer for total amount of data and files once more.
Yay, the explorer.exe from both windows sides, now report exactly the same number of files and same amount of storage consumed by them at both places. Suppose its really in sync now.
will shut down syncthing now and send logs.
Unfortunately the same error didnt happen again this time, but maybe something is visible or deducible from these logs?
Unfortunately not, the error needs to happen, otherwise I don’t know what to look at.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.