The current approach is quite sensitive… It prevents non-techy users from screwing things up, while still allowing power users, who know what they are doing, to easily change folder paths. It kills two birds with one stone this way. And I’m saying this as someone who does modify paths quite often.
Also, if this was to be made accessible to any user, then you would really need to implement a proper folder picker first (instead of typing the path like you do now). This would likely require a lot of work, especially considering all the different operating systems that Syncthing supports.
I just don’t see the goal of Syncthing being to change local files in and of themselves. I agree with the current approach towards this issue. Works well for users of all levels.
I don’t think there’s a list of “all” the cases. At least I’m sure I don’t know all the cases, and that’s part of the problem. But I can imagine some of them;
User wants to change where the folder is and expects all the local files to be moved
… to somewhere else on the same filesystem, so we could mv the dir.
… to somewhere else on another filesystem, so we need to copy everything and then delete.
… which might fail half way through due to out of space or whatever other reason on the destination or read error on the source
… or syncthing may crash or be stopped halfway through, so we need to somehow keep track of what we’re doing persistently and be prepared to roll back or continue on startup
User made a mistake when they added the folder and meant to point to somewhere else
… so we should forget the files there were already there and restart from scratch
… so we should mark the files that aren’t there any more deleted so they are removed on other devices
… but not files we maybe had time to sync there from somewhere else, presumably
and so on and so forth. This is just limited by imagination – and not my imagination, but the imagination of the 250k+ users out there who will use this feature and assume it was just made to do precisely what they expect it to, because that’s the only thing they could imagine right at that moment…
The only thing I’m 100% sure about is that “just mv the folder” is precisely not the correct answer.
By the way, I just wanted to add that although @cregox your idea is almost uniformly opposed. I would like to point out part of what makes Syncthing such a great piece of software. The functionality is excellent, but so is the community. The creators respond to questions, concerns, and feature requests in an intelligent and nondictatorial fashion. If you convince the creators and community that your idea is better I have no doubt it would be implemented. This just doesn’t happen across so many other poorly managed projects.
how about the idea of implementing what “removing a folder and adding again” already do?
drop the previous “folder id” and create a new one… except on the path thanking it would be with the same id and settings intact.
this should probably:
pause the folder and then trigger a new scan
give a warning there might be consequences on the shared devices if the folder is greatly different, as expected.
get lots of users who would ignore the warning and unpause the folder right away.
if the new folder is then empty, bandwidth issues could arise, sure. or storage, or whatever. but then users will eventually learn they ignored the warning.
the sooner they realize (and most users will only suffer such thing once because they will then learn to at least properly monitor their changes) the sooner they can simply rename it back and/or pause it to properly move the files as needed.
save all our most settings, such as shared devices connections. a lot of rework that don’t need to be done
i believe users are not really always trying to break stuff, that’s just a safe mindset to have on the dev side, which also needs to be loosen up at times.
I’m not feeling we’re getting anywhere here. I showed you that there are multiple different scenarios with different user expectations, and in all cases bad effects if the user expectations don’t match what we actually do. Your response is again essentially “let’s just do this one thing”, which only does the right thing in some circumstances and otherwise does the wrong thing? OK.
Even if you apply a solution to the scenarios above the point is that there are an endless number of scenarios which would result in problems. Unless a rule is created to mitigate harm in every conceivable scenario (impossible) the option will create a serious issue in at least one instance.
Also, why direct resources at endless logical rules to prevent harm when changing file structure through the GUI when resources could be directed at untrusted (encrypted) nodes?
I am not opposed to making the folder path editable in the GUI by default without the path having any effect on the existing file system, but I just checked this can already be done. Why don’t you do the work and submit a pull request making folder path editable by default?
Worst case you can release a fork with folder path editable in the GUI by default.
