As the explanation could be complicated, some pictures will show the problem in a pretty obvious way (even if it’s french, it’s about amount and size of files)
This forum doesn’t let me send several picture so I’ve prepared one big picture with everything in it
The problem appeared for some folders few weeks/month ago
Do you have an idea of what is going wrong ?
I would say that the problem may be on the Windows Server machine (source) with syncthing seeing some of the folders 2 times (with short and long name).
What version of Syncthing are you using? Are you using inotify?
IIRC there was a problem some time ago, that in some cases, inotify (I don’t remember if it was the external or the internal one) sent the short names (as that was what Windows told it). As that folder exists on disk, it was added to the index.
If you are on the current version, you should try renaming the problamatic folders and wait for sync. Then rename them bak.
Yes everything is on the last version as soon as it’s released, on the Windows server side, I’ve placed the Syncthing executable where the executable can be upgraded automatically and on the Linux side I followed the tutorial about adding the up to date Syncthing source into source.list, and unattended-upgrade is programmed to apply updates for Syncthing too.
When the “file watch” feature have been added I enabled it on all of my Syncthing running
Thank you AudriusButkevicius, of course your answers could help people to save a lot of time and effort : if a problem doesn’t exists or if a feature have no chance of being useful, then starting from this principle can obviously simplify everybody’s life and also helps you to develop Syncthing in the most efficient way.
But abusing this ability isn’t always the best way to help
Sorry, I missed that, yes, this seems wrong but I think we already have a ticket tracking this, but my gut says that it was fixed. If it’s already fixed, then you should understand how to reproduce it and open a new one. If it’s still open, then sadly just watch that ticket and hope that someone cares enough about it to look into it.
It’s quite possible that the problem appeared on a previous version. I noticed those folders few weeks ago when the replication target’s Syncthing WebUI was restarting in loop - 2 or 3 weeks ago : I erased the index-v0.14.0.db folder, in order to let Syncthing reconstruct a working database. Then I saw those XXXXXX~1 folders being analyzed by Syncthing, I felt like those backup files were completely corrupted so I deleted everything, and let Syncthing do the full job again from scratch (to have a something clean on the replication target).
Then yesterday in the evening, I noticed that those XXXXXX~1 folders were back on the replication target, and coming from the source Syncthing (Windows side)
To answer some of the questions, yes, on the replication target, folders are appearing several times and are occupying several time the size.
What I’ll do this evening (100 GB of transfer are remaining, so it’s 97% completed, I’ll wait for it to be terminated) is to turn off Syncthing on the source side, erase the index-v0.14.0.db folder, and let Syncthing at version 14.52 rebuild a clean database.
If everything is fine, then, on the replication target, XXXXXX~1 folders should normally be deleted (transfered to .stversions) then I’ll carefully delete those folders by some “rm -rf” commands from the .stversions folder
Depending on what you are doing exactly and/or how much my train of thought is messed up, that’s not necessarily the case: If the XXXX~1 dirs exist on replication, the windows source will check those files, they will look ok (because win internally resolves it to the correct name) and nothing happens. If you delete them on the replication, the win side will also pull the deletions, which again is resolved to the normal filename. You probably need to reset database on both devices at the same time (if you have multiple folders, but only one is affected, it is faster to just remove the affected folder instead of resetting the entire database).
We could be smarter about this, by also checking for win8.3 filenames when pulling and when detecting a conflict, throw some kind of error (possibly “merging” by conflicting the two copies).
I didn’t have the obligation to reset both data base since source is “send only” and destination is “receive only”.
But it seems there that it only worked fine because the source is “send only”, as the receiver tried to send its version to the source (despite the Receive Only mode - probably because he considered those files to be Received from outside before).
Anyway, it was so slow that I had to reset the second database too
I just noticed that, at the backup side, reconstruction and syncing to the other machine is much faster when
Both are online and seeing each other during reconstruction (if not, you have a fast reconstruction before, and a very slow sync check after, with only few files per seconds… on Millions of files it can be days of checks !).
The “Override” or “Cancel” changes buttons shouldn’t be pressed until syncing is terminated and only few files that actually changed are remaining “Out of Sync”
Folders “Pause” mode should be disabled one by one for having Syncthing working only 1 folder at a time, and maximizing HDD efficiency.
