Without auto accept checked, the remote machine folder path has a subfolder. that is …years/2020 will have …years/2020 in the path when it asks you to accept it. With auto accept checked, the remote machine creates a folder without the ‘/’ so no subfolder, just a longer name for the folder. that is …years/2020 will create the folder …years 2020
Makes it really slow to add a many years to my years folder. I end up editing the config file.
That’s intended: It’s part of the sanitation of the folder label, as some letters are not allowed on many OS/FS and others may be allowed, but have weird consequence (pipes in shells, …). However I see the value of interpreting slashes in folder labels as path separators.
Using slashes in the folder label is actually a great feature for exactly this reason. One can communicate a suggested hierarchy of shared subfolders below the default path. It currently works when manually adding a suggested folder (pre-filled folder path), so I think the auto accept feature should allow it as well.
I am actually using that to keep a common directory structure while selectively sharing only parts of a larger tree among nodes.
Note that it even works across platforms, since Windows natively does accept a forward slash as path separator as well!
yes that is exactly what I am doing, and I think it is an important feature. So I consider it a bug that it does not work with auto accept.
Yes I see possible problems but the way it is is inconsistent between manual and auto. I don’t know about mac or android, but on windows10 and linux it seems to work when I do it manually (win10 shows a forward slash but makes the sub folder if you just press ok) but with auto accept it doesn’t make the subfolder just a folder name with a space instead of the slash.
Maybe I’m missing something, but… Why not just have a “years” folder in Syncthing, which contains multiple subfolders? Do you need to selectively give people access to different years?
I don’t think you can take some behaviour that’s working as intended and call it a bug. A bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways[1]. This is working as intended. You can request a change to that behaviour, but calling it a “bug” doesn’t mean much.
sure, may not be a bug, but it is not working as I would expect. I would expect the suggested manual path to be the same as the auto accept path. and personally I would prefer them to both have the slash in there. (note that I haven’t worked with android or mac, and have not checked older versions of windows, so there could be other problems)
Why not have a years folder? Yes that is what I have. I have about 20+ years with 50000+ files and 150G space. So I want to just sync a single or selected years. Under the year it goes months and Days.
What I’d do is add the top level “years” directory as the folder, and then ignore the years you don’t want to sync. Ignore patterns:
/19*
/200*
/201[0-5]
for example, if you want to ignore everything < 2016.
For this specific use case that would work as an adequate structure. My use case consists of several independent projects where not all people involved should have access to the same subset. However, for those that share multiple project folders, the directory structure should be consistent at least for what is suggested when adding.
In short: I agree that it would make sense to not filter out the forward slash when auto accepting folders. Any possible abuse is limited to people the user enabled the auto-accept feature for, so kind of trusted parties. They could just as well DoS us with huge amounts of data, regardless of a flattened or hierarchical folder structure.
That is not a bad idea, but I have it done each one separately now, and it seems maybe more work, but simpler and more obvious (at least to me).
What are the downsides or problems with interpreting slashes?
I’m probably not the one to answer that, I don’t see any in this case, but in general the worry is a hacker may find a way to crash the system and/or get access to something he shouldn’t.
First and foremost, in my opinion, that a folder label is not a path. I might for example create a Syncthing folder on my Windows computer, label it Fall/Winter 2019 because I deal with fashion, and share it to my Mac. The slash does not denote any form of hierarchy and the slash is not the usual path separator on Windows either. Creating directories called just Fall and Winter 2019 based on this would be unexpected.
We must then also have logic to prevent escapes (../secrets) and unexpected nesting of one folder inside another (foo/bar and foo/bar/baz as two different folders). The latter would allow injecting data in another folder you don’t share or escaping (by pointing at a symlink in another folder).
It’s also a complication from the more general rule “odd characters are filtered when constructing the directory name”. We do want to continue filtering other specials like dollar signs and characters not possible in Windows file names.
All in all I’m very disinclined.
I understand, security is a show stopper, I would expect and would like the “unexpected nesting”, but see a real problem with security traversing up the tree. Seems symlinks might be a problem already? but if there is a way past that, I wouldn’t expect Fall/Winter to changed to Fall Winter without a warning somewhere, maybe it is changed in the folder path when adding the folder. that way it can be edited, and on the other end when the folder is auto generated the folder name would come from the added portion of the path. That would cover the “Label is not a path” part.
I agree that the security implications and possibly unexpected behavior would make things overly complicated.
Just please don’t start filtering when filling the suggested path for manual adding. I find it very convenient to have the slash there, and since it is only a suggestion to be edited and acknowledged by the user, the responsibility lies with that person.
The only reasonable change I could wish for here would be to replace all slashes by the OS path separator before writing the path to the config file. That avoids a mixture of backslashes from the default path config and slashes from the suggested folder label.