I’m a little confused about how to get my setup to work
To start with, I have a Debian VM “Debbox” that I use as “introducer” to other devices (I think of it as the “hub” between all the devices)
I have a w10 laptop on which I do most my work. I cloned the SSD from a desktop, so most of the files were already present when I set it up
I re-installed Syncthing (Synctrayzor 1.1.24) on the laptop and added the device (new name) to my main Syncthing VM “Debbox”
Since then, I have created new files in some of the synced folders, but my files are not being sent to the other members, and I am getting this error on the laptop:
handling file: file modified but not rescanned; will try again later
And also this error:
no connected device has the required version of this file
BTW I have the “Introducer” Debbox set to “auto accept”.
At a guess, you might have files on the two devices that differ only in case (document vs Document). This results in really odd things, like what you’re seeing. It’s a bug, unfortunately one that’s tricky to solve.
Well, as a starting point, I realized the package maintainer’s version of Syncthing is v1.0.0 while Synctrazor’s current release 1.1.24 ships with Syncthing 1.4.0
I downloaded 1.4.0 on my Debian machine, stopped the systemd service for it, and am running 1.4.0 from user prompt as a test to see if that clears anything up.
Didn’t fix anything just by getting the versions to be equal. Just restarted Syncthing on Windows and it’s giving me the same errors:
handling file: file modified but not rescanned; will try again later
Failed to sync 73 items
isn't making sync progress - retrying in (...)
no connected device has the required version of this file
I’m bummed, I was really hoping the upgrade on Debian would do it. I’ve gotta find some way to get this resolved, I rely on Syncthing (and these files) a lot.
Specifically, this person tried a test with mv-ing a file to a version with case, and when syncing the file from Linux to Mac, the file actually disappeared - and then deleted the Linux copy, as well!
Pretty scary. Thank god I have .stversions set up.
In my case, I created a file ‘testfile1’ in Linux, observed the file being synced to Windows - and also this error message:
<foldername>: Failed to sync 1 items
Renamed the file in Windows to Testfile1 - on Linux both exist:
testfile1
'Testfile1 (Case Conflict)'
If this happens en masse, it’s going to be a huge PITA to clean up.
On Android, in the Syncthing app there’s a “reset db” option under “troubleshooting”
Process:
Stop all instances of Syncthing on network
Delete all index db files on all devices (rm * inside the index-db folder)
Restart Syncthing on all devices
I started by running Syncthing on the laptop I was having issue with first, too - since it had all the new files that weren’t being synced. I am not sure if this made a difference, but I thought it might be worth mentioning.
Hope I don’t run into these issues again, but at least Syncthing is pretty friendly about rebuilding its indexes after being manually deleted.
It’s important to note, I am going to make all my Syncthing folders in Windows case-sensitive. (I had no idea I even could - apparently it’s a feature that was added in 1803)
Article:
Update:
It can be kind of difficult / time consuming to do this for each folder, so I looked up how to do it recursively using a PowerShell script.
Here’s the process:
First, you have to enable WSL to be able to implement case sensitivity in Windows
The first command that enables case sensitivity recursively doesn’t enable it for the folder it’s run from, so it’s necessary to run the first command and then change to the parent directory and run the command for the single folder on the folder you were just in.
Hopefully now I won’t see any of these case sensitivity mismatch errors anymore.
This process I used also with v1.4.0 and since this timepoint all devices runs perfectly.
The change in the database structure since the last version 1.3.4 needs a Migration after update to the current version, but is not working in my cases.
Just to prevent any misunderstandings by people reading this:
The upgrade to 1.4.0 does not require a database reset.
Resetting the database should never be done lightly - create a thread on the forums discussing your problems and the way forward first. @averyfreeman did their due diligence first and found a solution that worked and that’s great. With lesser care you might just create more problems instead.
Migrating the database requires reading and re-writing every file entry, and in some cases this turns up pre-existing corruption. We’ve put a fair amount of thought into repairing and fixing such corruption when encountered, but sometimes there are cases we didn’t anticipate.
There’s tens of thousands of users on 1.4.0 and a handful of known migration failures so far.
I don’t think this issue had anything with the migration to do.
It wasn’t meant to be like that. Of course the reader have to know the story you both know about it in my cases. I did not mean that this is generally necessary. As you know, there were things that I couldn’t fix with the available tools, maybe I have Synologys or because of others reasons.
That is why I also expressly say here that anyone who changes from <v1.4.0 to v1.4.x does not have to do anything if all processes are running.
Yes, thankfully I only have ~10GB of synchronized data. I couldn’t imagine doing it with far more than that - I think I read one thread where re-creating the db (rescanning all the files from scratch) would take upwards of 10 hours, so not everyone will think this solution is all that ‘easy’.
