Folder path not created


(Clemens) #1

Yesterday I have upgraded to version 0.14.50 and ran the same distribution setup as every night. I got an new error, which did not appear before:

[RWMBZ] 20:03:29 WARNING: Error on folder “image_folder” (image_folder): folder path missing

This appeared on 2 of the 11 receiving Windows devices. The folder is created by a script that changes the config and usually the path is then created by Syncthing on the remote devices. I could not find any error messages why the path could not be created. I checked for the path on the machines and it was not there.

I reran the parts of the script that share the folder and this time the folder was shared on all devices.

Do you have any idea what could have caused Syncthing to not create the folder the first time?


(Jakob Borg) #2

The folder is not recreated if the index says it already should exist and contain files.


(Clemens) #3

When does the index database remove the information about folders? When the folder is removed in the config or only at some other reset point?

I am creating folders with the same folder name and id every night, but the path changes from day to day. This means that there should never have been a folder with the desired path in the index.


(Jakob Borg) #4

Path is not relevant, only folder ID is. It’s removed when removed from the config via API or when starting up.


(Clemens) #5

I could append the date to the folder ID, but the problem should not really exist since the folders are removed from the config through the API and restarted 1h before the sync process begins due to my problem with the slow down of the sync.


(Jakob Borg) #6

Yeah. But it sounds like you do run into several odd problems, and without being able to share clear logs you might not be able to get much help. I still suggest looking at resource usage (closely; including I/O latency & queues, etc) when you see issues and when you don’t. You may be triggering some corner case by the unusual config changes etc.


(Audrius Butkevicius) #7

I think its actually removed only after a restart.


(Clemens) #8

Does that mean that the database will grow infinitely if I never restart and add huge folders daily?


(Jakob Borg) #9

No, we definitely clear the data when it’s removed by config push.


(Clemens) #10

Ok. I will be careful that I do not leave a shared folder with the same ID and if it happens again, I will add the date to the ID.

This might be just another workaround for a deeper underlying problem, but I cannot find any suspicious resource data.


(Audrius Butkevicius) #11

I know there was a bug where the folder id to int mappings were not dropped, and I know my fix dropped it on restart, because if lets say you shut down syncthing, modify the config externally, and start it back up, that would not clean up everything. Perhaps dropfolder drops the ids too, but I am on the phone, hence can’t check.


(Jakob Borg) #12

I don’t know if we drop the IDs, there’s no real reason to do so anyway. And yeah, it used to be that we just cleaned on startup, and we of course still do so for the reason you mention.