Getting this error on one specific folder I have set up on my share cluster of 2 computers. The error shows up on 1 of the computers, on the other computer it just says “Up to Date”.
I just deleted and re-set up sharing of that particular folder (including the ignore patterns on both machines in the cluster) to try and get rid of it, but no dice.
I’m seeing from other threads this is an issue people seem to be having, any clue on how to fix this?
It’s most likely caused by a case only rename. If you know which part of the path is causing it, you can rename the path to something else and rename it back.
If you want to start fresh, you have to remove the folder from both devices (to reset the state on both sides) and readd it afterwards.
If you remove it and readd it on one side then the other, then it’s pointless, as the other device sends the old state across.
It was a remove & re-add on both sides. Then I re-added on machine 1, shared with machine 2, and machine 2 showed the error right away without ever being “Up to Date”.
Is it one specific file? Perhaps it’s some database file that changes faster than we can detect changes and scan it.
I am also very frequently getting the message “finisher: file modified but not rescanned; will try again later” I have 5 machines that are all windows machines and are all on a local LAN. If I make a small change to each file that has this error such as add an underscore to the file name, the file will then usually sync. I have hundreds of files causing this error in multiple folders, so it will not be easy for me to rename each individual file. What steps can I take to try to determine what is causing this?
You probably did a case-only rename of the filename or some directory along the way that is now causing this. This is a known issue.
I’m encountering a very similar problem.
I have a folder in Syncthing containing several files which don’t seem to be syncing properly. Clicking on the “failed items” list reveals the following error message next to each item: “file modified but not rescanned; will try again later”. Clicking the “Rescan” button to try to force a rescan does nothing to resolve the error.
Additionally, my directory seems to contain slightly older revisions of each of these files, with names like ~syncthing~<some_file>.tmp, which I can’t get rid of. Every time I delete these extra files, Syncthing just puts them back a few minutes later.
One way I’ve discovered to fix this is to delete the files (new and old revisions), wait for Syncthing to put them back, delete them again, wait for Syncthing to register that they’re gone, then restore the files from a backup copy. That’s very inconvenient though, and this sync issue seems to be happening fairly frequently (mostly with files I’m actively working on).
Do you have a link to the GitHub issue for this bug so I can subscribe to be notified when it’s fixed?
It’s most likely caused by case only renames. You can search for issues with “renames” in github, but I wouldn’t hold my breath as the issue has been open for a few years.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.