I have two Macs, on Sonoma, using Syncthing. One, named Aule, is on 1.26 and the other, named Cirdan, is on 1.25. I had some issues with the upgrade to 1.26 (apparently part of the browser interface error that is related to the login issue), so I haven’t updated the 2nd system to 1.26 yet. Waiting for the bugfixes before I do that. The folders are all shared bidirectionally, so both systems will always be up to date, regardless of which one I was lately working on.
This has been the situation for over a day: Cirdan reports Aule as only 59% updated. I’ve restarted both systems multiple times, but there’s no change. It seems that Aule is just not getting updated from Cirdan. On each share, I created it on Aule, then went to Cirdan and accepted it as a share.
What’s going on here and what do I need to do to make sure both stay fully updated with each other?
On device “Cirdan”, take a look at the list of out of sync files by clicking on the blue hyperlink labeled “302 items, ~373 MiB”.
It’ll open a pop-up window that lists the items. If the error is to long, it’ll be truncated, so hover the mouse pointer over the item to see the full message.
Quit Syncthing on both systems, then ran /Applications/Syncthing.app/Contents/MacOS/Syncthing --reset-deltas, went back to my browser and reloaded the web interface on both. Nothing was different - as in same info, same displays, and son.
So if it’s a bug, what do you need to help troubleshoot it?
Was this right after using --reset-deltas? I’m asking because resetting deltas usually takes a while, as Syncthing needs to re-send full indexes between the two devices, although there isn’t that much data in terms of size here, so the whole process may have just been very quick.
Are you able to narrow down a specific folder or folders where the files that can’t be transferred belong? If yes, can you see anything special about them?
It was right after, but it’s been 34 minutes now and it’s still like that.
I’m not sure how to narrow down the folders that might have an issue without doing a comparison between machines and, since Aule says it’s completely updated Cirdan, I won’t see a difference. I’ve looked at the output from both versions, since running them on the command line. I don’t see any report of any error. The one thing I see that I am not clear what it means is this:
The “Local State” under “This Device” on both devices should be identical, however it’s not, so you can try comparing local states of each folder and see whether any of them differs. If it does, then you can try to remove the folder and re-add it (you can trigger the “Add Folder” pop-up by pausing and unpausing the remote device). I’m assuming you don’t use any ignore patterns that can cause the different local states.
On both systems, the directory status, for each directory, is “Up To Date.”
However, I realized I have one issue where I use excludes (actually an include) and I have a warning on it. I’m syncing only one file in a directory, but that directory is also the parent to another folder where the full directory is synced.
First item:
Directory: ~/Library/Preferences/
Ignore patterns:
!*iterm*
*
Second Item:
Directory: ~/Library/Preferences/Carbide 3D
(No ignore patterns used on this item.)
(Please - how do I get this forum to recognize a cr/lf at the end of a line that is marked code or that starts with bold text? I have to keep skipping lines for readability!)
My understanding is that my ignore patterns should ignore everything other than any file with ‘iterm’ in it. When I check the status on both items, the first with the ignore patterns and the 2nd that’s only a folder, they both show up to date and the information on both is the same on both computers.
I’m looking over all my other entries to find issues. I did realize I had some instances of programs running, so their config files may be locked. (I anticipated this early on and made a rule that if I’m syncing configs for a program, that I only use it on one computer at a time. I guess I’m still not in that habit.)
I wanted to post this while I’m still checking things over to find out if this particular issue could be significant.
One question that has come up while I’ve been checking over my other sync items: When I have a folder synced between both systems, and I’m looking at the folder issue, the “Latest Change” is going to be for that folder on that computer, right? So it might be one thing on one computer and a different thing on the other?
With some problem directories, I deleted the entry, then remade it. I’m doing that on my main system, Aule. When I do that, I check the web interface for Cirdan and it sees the share and asks to add it. I click to accept, but, initially, I want the data to come from Aule and go to Cirdan. So, on Cirdan, I set it for “Receive Only.” (I figure once it’s all synced, I’ll change it so both are “Send and Receive.”)
Every time I do this, I get Sync Stopped as a status on that directory entry, with the reason being the directory (I think .stfolder) is not there. I don’t know what’s going on, since Syncthing should have permission to write to all my folders, especially when they’re in my Documents directory and I ran Syncthing from the command line.
So when something is wrong, deleting the entry on both systems, recreating it on one, letting it propagate to the other, and setting it as “Receive Only” so the other system can get the source from my “main” workstation always results in stopping synchronization and not being able to create .stfolder in the proper directory.
I had to take off and nuke the whole thing from orbit. It was the only way to be sure.
I just kept running into more and more errors, so I stopped Syncthing on both systems, deleted the config files on Cirdan, then installed 1.26 (since upgrading from 1.25 to 1.26 on Aule created problems, I wiped everything from Syncthing out first). Then I added the new setup on Cirdan as a new device for Aule and added the shares to it, then went to Cirdan and added each one in turn.
I’m not sure, but I think the issue is that I have the one folder setup to read one file in it and that folder is also a parent of other folders.
I mentioned that above. Basically, I have some files for iTerm2’s preferences to sync:
I’ve set them up on Syncthing using the directory they’re in, but then added the ignore specs:
!*iterm*
and:
*
That seems to work and shares the files with “iterm” in them. The problem is I have two other shares:
~/Library/Preferences/LightBurn
and
~/Library/Preferences/Carbide 3D
My problem is I need to share all those (the iTerm2 files and the two other preferences directories), but it would be a serious problem to just share ~/Library/Preferences, since that could mess up a lot of programs.
When I set up ~/Library/Preferences and use the ignore patterns, Syncthing realizes that is the parent directory of the other two shares I listed. I think this is setting up a conflict, even though the ignore patterns make sure the other directories are not shared.
You should make sure that multiple folders don’t try to sync the exact same files/paths. If they do, there will basically be a race between them to sync them first, and you may meet various unpredictable consequences.
If you do need to sync folders that share same paths or are in a parent-child relationship (i.e. nested folders), then you need to make sure that the child folder is ignored in the parent folder.
Due to using ! negated patterns followed by *, you may be hit by https://github.com/syncthing/syncthing/issues/8735 which leads to slightly incorrect global/local states and some folders seemingly stuck in sync.
That’s what I’m worried about and since I was getting reports indicating the syncing wasn’t done - and the status for each directory indicated it was done, I figured maybe there was something that made tracking transferred data a problem.
I think that’s the case, since I have the “!iterm” to include files with “iterm” in them, but the wildcard “*” to make sure it excludes everything else. I think I have that correct (and I understand the includes need to come first, since if I exclude everything, it won’t read what I later include). Does that seem correct?
Went over this a couple times to be sure I understood it all. Several thoughts on it. While what I’m getting is not the same (the only files I want to unignore are in the first directory level of the configured share), I would be surprised if the bug causing the nested directory issue is NOT related to the one I’m encountering. I’m sure both trace back to the same section of code.
One difference I seem to be seeing is that the status for the individual folders as okay, but the error is showing up as the status for the linked system - and it’s only a problem on one device, not both. (But if I understand it correctly, you were also only seeing errors on one side.)
I’d like to know about how you’re testing. How are you doing this without messing up the settings for the machines you’re testing on? I was thinking I could do a test by backing up the configuration and log files on both computers, deleting them and setting up a new configuration. Unless that creates issues, it’d be a convenient way to test, and it’d allow backups of several test configurations.
Right now I have 23 directories set up for syncing, so I don’t want to have to redo that lengthy setup process. Does backing up and restoring the configuration work without a problem?
Also, I notice you talk about specifying each directory specifically in your ignore specs. I’m wondering if it would make a difference to me if I specifically exclude the folders from the first share (the one where I only need to share a few files in the directory) that are in other shares. In other words, specificity might make a big difference. If that’s the case, that’d solve my problem - but I don’t want to do this if I have to redo it all again if the issue pops up again.
