Is there any way to force a particular share / file to be authoritative?

I have a syncthing share that is stuck on some files that were deleted during syncing (files under the .git directory). Unfortunately, this is causing the puller to complain and fail syncing however which way I manually triggered re-scans on both the source and destination laptops.

The source folder is on a laptop named lenneth, the destination folder is on a laptop named lezard. They have a common share Projects which is my catchall folder for basically all git repos and software I’m working on. Have never had a problem with the Projects folder before, but apparently somewhere during adding this one repo one or the other daemon got disconnected or something and now lezard fails to sync Projects, always failing on these files:

[IEEVH] 13:03:53 INFO: Puller (folder "Projects" (Projects), file "madumlao-profile/.git/COMMIT_EDITMSG"): finisher: pull: peers who had this file went away, or the file has changed while syncing. will retry later
[IEEVH] 13:03:53 INFO: Puller (folder "Projects" (Projects), file "madumlao-profile/.git/index"): finisher: pull: peers who had this file went away, or the file has changed while syncing. will retry later
[IEEVH] 13:03:53 INFO: Puller (folder "Projects" (Projects), file "madumlao-profile/install.sh"): finisher: pull: peers who had this file went away, or the file has changed while syncing. will retry later
[IEEVH] 13:03:53 INFO: Folder "Projects" (Projects) isn't making sync progress - retrying in 8m0s.

I’ve force re-scanned the folders, restarted syncthing then force re-scanned, force rsynced from one to the other then rescanned, force deleted and recopied on one then rescanned, force deleted on both then re-scanned then did a fresh copy to one, forced deleted on both then tried to do a fresh git clone, etc, but the puller always seems to think it can’t move forward due to the failed items.

At this point I’m not interested in figuring out why the puller failed. I just want to mark one share authoritative (the laptop I’m working on, lenneth), and have the other one (lezard) carry on syncing from there. Is there any way to do something like this, like manipulating indexes or something? – without having to recopy the share from scratch (tens of GBs) that is. Bonus points if it’s only limited to the failed files.

You can’t make one of them authoritative. It’s a p2p system where all participants are of equal power.

There are tons of posts on the forum explaining why you should not sync git repos, and yours is a perfect live example.

You can try setting the folder that is in sync to sendonly (that is not authoritative, it just does not accept remote changes) and if an override button appears. If it does, you might get back in sync, but I cannot say if your git repos will not go corrupt.

The other (better) option is to touch the files in question and see if that makes it better.

By authoritative I don’t mean to add a permanent setting, I basically want to force some files through. Any way I can manipulate the indexes or something to make the known clean copy the one to use? At the absolute worst case, what I’m asking for is not fundamentally different than “adding a share where a copy of the files already exist”. It’s been a long time since I did that, though.

Regarding git, I control both peers and am only on one laptop at a time, there is zero chance for lock contention on git as the latest is effectively always correct. Syncthing is effectively just my “in case one laptop is destroyed / lost / dies, work continues as normal” system.

As I said, you can touch the files which will make the files latest where they were touched.

Touching the files and restarting / rescanning didn’t seem to have an effect.

However, I seemed to have luck when I manually deleted the .syncthing.FILENAME.tmp files from the folder in question via

find -iname '.syncthing.*' -delete

and re-scanned after restart.

I’m not sure if that actually made a difference, fact is I already ran so many combinations of “do this, restart, re-scan” that I might be mistaken which one actually forced the files through.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.