folder stopped/path missing when changing path the second time

TL;DR: Add / Save / Edit / Remove / Add / Change Path / Save ends up in “folder path missing” when sender not paused

Without ‘Change Path’ the error would be ‘folder marker missing’ which is expected.

In Detail: I want to share a folder ‘A’ from ST1 to ST2. After accepting I delete the shared folder in ST2 again. When it gets offered again I accept, change the path from ‘A’ to ‘B’ and ‘Save’. Immediately the accepted folder is ‘Stopped’ and an error window pops up stating “Error on folder “A” (A-folderid): folder path missing”.

‘Pause/Resume’ on ST1 immediately forces the request to pop up on ST2, so I did that.

Bug?: When I just pause ST1 ‘A’ everything works fine. I can change the destination path on ST2. Whereas when I pause/resume ST1 ‘A’ I cannot Remove/Add to a new “Folder Path”. I ends up in “folder path missing” and “Stopped”

Steps:

Two vanilla syncthing ( ST1 and ST2 ) connected to each other:

ST1 offers to share its ‘A’ folder with ST2:

On ST2 I accept the offer by pressing “Add”:

Without changing anything I press “Save”:

So far, so good. ST1/A and ST2/A are in sync.

Now I want to change the destination folder on ST2 from ‘A’ to non existent ‘B’.

‘Remove’ folder ‘A’ in ST2. Open A:

‘Edit’ A:

‘Remove’

‘Yes’

Now it looks like as if A never existed.

‘Pause All’ on ST1… BANG! ST1 wants to share on ST2

‘Resume All’ on ST1

‘Add’ on ST2 to add new folder:

change “Folder Path” from A to B

‘Save’

Now Folder A gets ‘Stopped’ …

and a few seconds later the error pops up:

“Error on folder “A” (A-folderid): folder path missing”

Notes:

To enforce “ST1 wants to share …” on ST2 it helps to “Pause” the folder on ST1. If the folder is not resumed I am able to change the destination folder: As long as ST1 is paused, I am able to change A to B and sync. Weird.

Setup:

2 x local running syncthing, silenced by manually editing config.xml to prevent discovery, ur, announcement, broadcasting etc etc.

$PREFIX = current working dir

ST1 - listening on 127.0.1.1:8384 - --home = $PREFIX/st1-home - defaults folder path $PREFIX/st1-default - to be shared folder $PREFIX/st1-default/A with FolderID ‘A-folderid’

ST2 - listening on 127.0.2.1:8384 - --home = $PREFIX/st2-home - defaults folder path $PREFIX/st2-default

2x Chrome/Brave on http://127.0.1.1:8384/# and http://127.0.2.1:8384/#

2x xterm with ‘tail -F st[12].log’

both syncthings married via syncthing cli config device add

helper script usage:

./testbug.sh init  # setup & start two married syncthings
./testbug.sh test  # create folder on ST1 and offer to ST2
./testbug.sh cleanup # stop syncthings and delete logs, config and data
./testbug.sh stop  # stop syncthings

testbug.sh (4.3 KB)

Logfiles:

st1.log (156.2 KB)

st2.log (248.2 KB)

Index/Config/Logs/Screendumps:

syncthingtest.tar.gz (3.3 MB)

For what it’s worth, changing folder path on the fly is not really something that’s “supported”.

But what about the ‘paused’ issue ? I am able to re-accept the offered folder to a different location when the sender is paused.

I don’t really follow what the issue is, sorry. Can you summarise what you expected to happed and what happened instead?

When I ‘Remove’ a synced folder and ‘Add’ it again I expect Syncthing to handle the ‘offer’ as new unknown Folder. This would allow to change the location for the cost of syncing all data again. Which is ok and wanted.

Some users tried to change location after blindly accepting the default and ran into this issue. So I tried to boil it down to minimal setup to reproduce the bug.

It’s not about ‘changing location’, it’s about ‘Remove’ and ‘Add’ ( … again somewhere else) .

I have a couple of reports of people with complicated setups and they (including myself) ran into this when ‘cleaning’ their setup. “Aw, snap, my camera pictures ended up in a folder called ‘DCIM’ on my NAS. Lets change it to ‘mypics’.” and sync again. I aware of the ‘changing location is not supported’ so I just ‘Remove’ it and wait when ‘Wants to share’ pops up again and then change location. The old folderdata (DCIM) on my NAS will be removed myself.

If I walk through st2.log I see the following timing:

443 [JWYKJ] 2023/02/16 11:47:09 model.go:2823: INFO: Adding folder "A" (A-folderid)
[...]
452 [JWYKJ] 2023/02/16 11:47:09 logfs.go:73: DEBUG: folderconfiguration.go:158 basic /home/wwwutz/syncthingtest/st2-default/A MkdirAll . -rwxrwxrwx <nil>
462 [JWYKJ] 2023/02/16 11:47:09 model.go:422: INFO: Ready to synchronize "A" (A-folderid) (sendreceive)

an on the second “Add” with '/B/ as location:

1750 [JWYKJ] 2023/02/16 11:50:40 model.go:2823: INFO: Adding folder "A" (A-folderid)
1757 [JWYKJ] 2023/02/16 11:50:40 model.go:422: INFO: Ready to synchronize "A" (A-folderid) (sendreceive)
1758 [JWYKJ] 2023/02/16 11:50:40 folder.go:150: DEBUG: sendreceive/A-folderid@0xc000249c00 starting
1759 [JWYKJ] 2023/02/16 11:50:40 logfs.go:115: DEBUG: folderconfiguration.go:116 basic /home/wwwutz/syncthingtest/st2-default/B Stat . <nil> stat /home/wwwutz/syncthingtest/st2-default/B: no such file or directory

no MkdirAll() …

I think this is a bug. Syncthing only attempts to create the directory when the folder is “new” (nothing known about it in the database), and I suspect this condition isn’t satisfied if the folder is removed and then directly added again.

Not exactly the same but probably related:

https://github.com/syncthing/syncthing/issues/8416

1 Like

It’s working as expected when I pause ST1. Here the logs say:

indexhandler.go:549: DEBUG: Not resuming index handler for device Z25X3SL and folder A-folderid as none is paused and there is no start info

But the failed ones log:

Indexhandler.go:546: DEBUG: Resuming index handler for device RYPMBTL and folder {A-folderid A basic /home/wwwutz/syncthingtest/st2-default/B

So maybe some ‘running’ indexHandlers[] are blocking the logic in indexhandler.go:528 folderRunningLocked() ?

funny enough the “Resuming index handler” is already using .../st2-default/B

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