Well, what I am seeing in the console window is the same exact message I see in webui:
23:57:58: Folder “Folder_name” isn’t making progress - check logs for possible root cause. Pausing puller for 1m0s.
But what does it mean?
What the real issue here?
One of my drives started behaving flaky as of late, and the physical share in question is located on that drive. At some point during the last boot that drive/partition just became invisible in Win, like it does not exist. After I rebooted, everything seems to work, except now I see this message from syncthing.
I run synthing via shortcut to an executable, and so it behaves as if I started it from the command box. No stdout is redirected.
Well, what I get in the command box is all normal messages, such as establishing connections, recognizing nodes, and then the same exact warning message as I see in webui, and it keeps retrying and displaying the same message every minute.
But what does it mean “isn’t making progress”? Progress doing what?
One of the things I notice is that on Win7 side (r/o) webui says there is 1 item out of sync.
But on the master side (r/w, Linux) it says 6 items out of sync. When I click on that message, I get these files.
What seems to be strange that some of them seem to be scheduled for DOWNLOAD to the r/w side from r/o side because I see these circles with down arrows for those files:
Yes, I am.
BTsync feeds the hot feed (live side) from Win7 to Linux.
Then Syncthing feeds that folder back to Win7, only to a different folder, “not too hot” in terms of frequency of updates.
Then BTSync serves that 2nd folder to all the r/o nodes.
This way, if we have too frequent of the updates, we can temporarily disconnect the Synching channel and so other users do not get overwhelmed be frequent updates.
Actually, I did remove some files and subfolders in the .stversions subfolder (the r/o side for syncthing) because I would not like these things served to other nodes, even though I have them in the ignore file. (That means that I removed some files in the r/o side (of synchthing), but only in the .stversions subfolder.
But I thought that you can remove anything you want in the .stversions subfolder.
Indeed, that’s odd. Mind doing a set STTRACE=model in a terminal window, starting syncthing from that same terminal window, and redoing the screenshot? There should be a bit more debugging crap between the “not making progress” warnings to help narrow down wtf is going on.
Folder Master - no
Ignore Permissions - no
Simple File Versioning
Keep Versions -3
I just tried to set Ignore Permissions - yes.
But that did not help. Still the same error.
This share worked fine before that drive which contains this share became non-existent to O/S, if that tells you something. At least these things correlate. But the strange thing about it is that I had the same situation a few days ago when the same drive just disappeared from the O/S. But that time everything worked fine after I rebooted and that drive started working again.
Right, so the only code path that doesn’t emit anything useful here (which will be fixed) looks like the case where it’s a directory, and it should be deleted, but the delete fails. The most common reason for that is that there are files in it, possibly covered by an .stignore. Does that make sense, at least so long that the .SyncArchive/.../..._Docs directory (I forget the exact name) ought to be deleted?
Yep, this is probably what’s happening here. When I deleted some files/folders in.stignore, it did have some subfolders in it and, possibly, just files on the top level. Unfortunately, I no longer have those files cause I emptied the garbage bin.
The .stignore did have .SyncArchive dir with subfolders in it. So, you’d have to traverse the entire tree to properly handle that case, as far as I can see.
Would it be too much of a pain to just handle this case instead of just printing a better looking message?
Yep, I’ll try that. Not sure what you mean by build 0+9.
Also, it is too bad that you seem to be so against a more detailed logging. The debug level trace isn’t that informative to the users and might be way to detailed to see the details of some operation and higher level calls. Also, I’d rather push some button and see the log window where it tells me exactly what is going on, which file is being transferred, it full path, and to which node and what is the higher level operation has initiated is, such as “sending/receiving folder/file xxx with node yyy”, or “doing periodic maintenance”, “rebuilding the index” and operational things like that.
Also, it would be very useful to the users to see the dynamics of transfers. There might be several nodes active at the same time with different state of completeness. I find it very useful to see the progress of things, percentage done, and things like that. Because simply seeing the total network speed and not knowing which exact files are transferred and to/from where makes one wonder or even doubt: is everything going on OK? How much do I have left with this share? What is the total size done by now? At what speed I am transferring the file and so on.
As I mentioned before, a detailed automatic logging to a session log file has helped me to find some pretty esoteric issues in a couple of minutes.
I’d really love to see a more detailed and more precise logging. But hey, life is life and your mind could be busy with all sorts of other things you think are more significant. Not a problem, I can wait. I’d just like to start bringing some people and serving exclusively via Syncthing and totally forgetting about BTSync. Because there is no day passing when I do not see some weirdest issues that should have never happened.
Meanwhile, what do I do now? Should I just remove that share and re-add it again in case you don’t need any more info on this? And, this may happen in the future, and if the same thing happens again, what’d be weird. Why not just handle this case properly and set the correct state for the files that are missing in the file system but are present in the database/index?
The same essential case happens when you restore some previously deleted file. In that case, the “physically present on disk” flag tells you if that file, when last seen, did or did not exist. If it did not exist, that means the file is being restored. So, you just mark it as “updatable” and “propagatable” and “phiscally present on disk” - true.
The same thing happens when you rename some files, and, possibly, decide to rename them back. I have gone through the entire update logic quite extensively and looked at every conceivable case, more or less, and it looks to me that there is a solution to the consistency issue if you apply much stricter rules as to updating the other nodes.
If you decide this case just “slide” and limit the handling to merely displaying the more informative message, I hope it will contain the instructions on what exactly one needs to do to fix this share, even if the message is too long and wraps around. It seems to me that more detailed information is more valuable than just merely being cryptic trying to fit it all on one text line, especially if you do not know the length of that line on different screens.
So, erh, not sure where I gave the impression that I’m against logging, or that what you’re seeing is not an issue that should be solved… The steps so far have been to just figure out what the issue is, exactly.
Practically, in this specific case, if the directory should be removed and syncthing can’t do that, you can probably resolve it by removing the directory yourself.