When I create a new folder on my local instance and use a path separator in the title, it adds the separator to the path (automatically, which makes sense!):
But when I share this folder to another machine, it gets the same label there, but the automatically generated path is different to the one added manually (local).
It would be great if the path would be the same remote, allowing the generation of sub-directories.
Otherwise (=workaround) I need to avoid sharing a folder until I created the folder manually on all other peers with the same folder ID, which is a non-handy work. If I forget it I need to delete and recreate these folders on the other machine.
To be honest, I think we should force folder ids to be letters and numbers only.
Thats fine with me, I didnt say anything about the ID 
Or do you mean Label ? Then I would totally disagree as long as there is no hierarchical structure of folders in syncthing.
PS I hope nobody mind but I realized that at least bugs should be maybe better in github: Inconsistent behavior of path generation local vs remote · Issue #6113 · syncthing/syncthing · GitHub
Ids used to be labels, so I still use them interchangeably.
Actually, I now recall this is intentional, to prevent attacks by people suggesting to share …\etc, and them not checking the resulting path.
Hm… When I put a label /etc this should create a folder in the default folder path, in this example /var/syncthing/etc (as a label etc would do). It’s not that a peer should be able to write a folder everywhere on the remote filesystem (like /etc).
Sure, but you can have double dots to go a level up etc.
If it’s possible to remove such characters, it should be also possible to just prevent .. or better just allow / and \ (for windows).
I think we should just remove all path affecting characters on both sides, as the label influencing the path is a terrible idea to start with.
For me it is very helpful 
As I have around 30 folder atm (would be more if it wouldnt be so complicated to maintain many folders) and they are in hierarchical structures which I wanted to reflect on the remote peer as well.
And because of a lack of hierarchical structure in the UI, I started using the folder structure as label.
BTW Google used the same concept in Gmail for the labels in the beginning, when they introduced the lab functionality “hierarchical labels”. When you disabled the functionality, you could see that the labels were simply a path, just displayed as a tree in backend when you enabled the functionality. This would also help the GUI IMHO. And a tree view to visually unselect paths within each syncthing-folder would be the master piece. But just dreaming 
PS maybe this kind of folder structure will become obsolete as soon as it’s easier to visually maintain ignores. No not maybe, I’m pretty sure though (starting from v1.3.1 when unignoring of ignored deleted folders leads to a restore instead of deletion on all peers)
Sure, it’s helpful unintentionally.
You can still do that by specifying the path yourself.
