How to fix a formerly synched >1TB folder?

I’m a user who hesitated to try syncthing for a couple years because it sounded like I might be getting in over my head. But about a year ago I finally went ahead. Now I have two 2TB drives with about 1TB-1.3TB of data on each synched between two computers (computer X and computer P) on a home ethernet connection. Both were set up in syncthing as send-receive folders. It’s been working well for around a year now through ups and downs of a few hundred gigabytes. Version on both computers shows v1.28.1, Windows (64-bit Intel/AMD). Syncthing is actually residing on the system/C drive on each, not in the data drives/syncthing folders, if that matters.

This past week I decided to try having Syncthing start automatically, as I have often forgotten to start it after a computer restarted (e.g., because Windows updated itself), only noticing after hours or even a day or two sometimes.

So I followed the instructions on the site to create shortcut in the Windows Startup folder and used the --no-browser option initially on one computer, and then decided to try the --no-console option, too. I did this first on computer X before later also trying on computer P.

Sometime after that, maybe two days ago, I noticed new files in one of of the syncthing folders (F) from computer X were not getting to computer P. I tried restarting Windows, closing and reopening syncthing, etc., but that didn’t help. So I tried deleting the automatic startup shortcuts and only starting manually again, but they still didn’t get transferred.

So I tried deleting folder F from one computer and adding back via invite from the other, and then got an error that there was no .stfolder (I did this more than once, and saw syncthing deleted it when I deleted the folder, but did not add it back when accepting the invite…my only guess as to why is initially I left a trailing slash in the folder path, like F:\ instead of F: only, which only occurred to me might be the cause because once I saw it showing a double slash, like F:\.stfolder). So I added the .stfolder back manually. I went both ways with this invite strategy, from computer X to computer P and from computer P to computer X, but it didn’t seem to make any difference in terms of solving the sync problem.

Also, at first I got computer X reporting the global state as exactly double the number of files and directories there should be. So I tried deleting the sync folder and adding back manually and for a seemed to get the correct numbers.

Anyway, I don’t really remember how many times I tried to delete and re-add on one or both computers manually or via invite, but at some point computer X just got stuck on a message like “preparing to sync”. I found it had created several hundred gigabytes of .tmp files, and the drive ran out of space (literally 1% left). So I changed the minimum free space to a safer level for Windows, first 10% then 20% and deleted all the .tmp files and restarted. Sure enough it just did the same thing, but stopped when the drive had 20% free space.

I don’t understand why it is creating all these temp files, as everything was formerly in sync except a few dozen new files created in the past few days.

Anyway went through that delete the temp stuff exercise a couple times and then after that noticed the file local state went to almost one-tenth of what it should be (~39,000 files vs. ~360,000 files). The folder count was also a lot lower, like 3,000 instead of over 10,000. Rescanning or deleting/adding back the folder didn’t fix it.

Just to try to cover all the bases, I did a test with the second folder/drive that I did not notice issues on, because I use it less so may have only missed an issue because I didn’t use it this week. I created a new file and directory in the root on each computer, and there did not appear to be any issues–both files and directories showed up on the other computer within a few minutes. Still seems to be fine right now–the file I typed this in was created in that folder and synched fine between both computers.

The most puzzling part of all is I even tried removing the syncthing.exe folder and folder it makes in appdata (after backing both of them up elsewhere), and downloading it again and starting fresh, but still got the same far-too-low local state file count, though the folder count looks correct now. Is there some other file or folder lurking elsewhere that I also need to delete to actually achieve an “uninstall” and “reinstall”? I couldn’t find one, so I just deleted the “new install” and put the backed-up original copies of the syncthing program and appdata folders back where they used to be.

I also then decided to delete a directory that had a bunch of files that never synched due to some permissions related to some nonexistent account, theorizing maybe those were tripping up the scan before it got through the whole drive, but that didn’t change anything, either. It never prevented synching the rest of the stuff before last week–I was just trying to narrow down possible causes of the problem.)

So I’m at a loss for how to proceed, wondering what could be going on here and how to fix it. Why did it stop synching in the first place? Why is it making all those temp files instead of recognizing the files exist on both computers? How come the local state on computer X is still so far off? How do I get syncthing on computer X to realize almost all of the data exists and is the same on both computers, with the exception of a tiny handful of files and folders created or deleted in the past few days?

You seem to have a lot going on there, but I just want to say that the .stfolder missing and doubled global state error is a known bug (see https://github.com/syncthing/syncthing/issues/8416).

As for the other issues, it may be difficult to troubleshoot without having direct access to the machines in question :confused:. I can only suggest to add some screenshots of the Syncthing Web GUI from both sides, as they usually help visualise the problem better than just going through a wall of text.

Well…most threads I’ve gone through trying to find answers seem to end up as a “wall of text” anyway, so figured why not just say what I did and saw already up front?

What info should be included or excluded in a screenshot?

I read somewhere someone had some issue that sounded kind of similar and downgrading to 1.27.12 solved it. I’m trying that now. I just checked the date of the 1.28.1 release and the timing is about when I started noticing problems, so it could well be that some bug in that upgrade is what screwed it up.

In any case, on first startup and accepting the problem folder share, instead of telling me the scan of that folder will be done in about an hour, it’s telling me more like 10-12 hours, which sounds a lot more like a full first-time scan, considering the size of over 1TB. And whereas the prior scans stopped around 39,000 files, this one is already at over 120,000. Makes me reconsider going with auto updates.

Well, the scan of the problem folder after downgrading from version 1.28.1 to version 1.27.12 finished overnight and now all the numbers for global and local match on both computers.

1 Like

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