why can't we change the folder paths?

You can’t change the path of folders, you need to create a new one (and delete the default folder if you don’t need it there).

feels like a little annoyance that was purposefully added for some reason.

The folder path can be changed. Have done it many times. Shutdown Syncthing, open the config file (if need location this forum can help), and change the folder path. Don’t forget to rename/move the folder as well.

1 Like

sounds awesome!

but my question still persists…

code wise, why was it done like this?

Even if the folder path could be changed within the GUI, the folder would still need to be renamed/moved at the file system level. I don’t think the goal of Syncthing is to change, move, or delete anything in the local file system. The goal seems to be to sync files from a folder on a different machine into a specified local folder.

It’s not obvious what it should mean for the local files if you edit the folder path, and any choice we make will be wrong or dangerous in some cases.

3 Likes

i guess i see what you mean…

when creating a new folder id, whether there are files there or not, we want to update the folder path.

but when changing the path of an existing folder id, we could want to move the files from the previous folder to the new, or we could want to just ignore the old ones… so that’s already at least 2 conflicting actions…

still, the GUI could pick the simplest one and make it first what it will happen with a message or better naming. could it not?

just a side note: the goal of syncthing is pretty much change, move, and delete many things on the local file system. :rofl:

that’s probably not what you meant, but i hope you can now see how the word choice there can become confusing.

We could, but it would be a “notice: if you misunderstood what this does we will delete all your files on all devices” style warning and that doesn’t seem great.

You can do this already by the way - it’s editable in the advanced settings dialog, and the warning at the top of the page says something similar.

I think the better option is a link to a doc article explaining the options available. The FAQ already says something about it. FAQ — Syncthing v1 documentation

3 Likes

where exactly?

perhaps the warning could be “renaming is only allowed with backup option on, beware”.

it does answer my question, but i was guessing the reasoning would be more sound. i still don’t see why it needs to be like this.

if it’s possible to delete it, seamlessly rename it manually with a simple “mv”, and recreate it without loss, so should it be to just automate this process within the GUI.

In the web GUI, I’m not sure where that lives on Android.

But that’s not always possible, and it’s just one of the many possible ways / reasons to change a folder path. At the risk of being somewhat snarky, this is one of those things that seems very easy when you don’t fully understand all the cases.

1 Like

No need to shut down :wink:. You can just pause the folder in Syncthing, then move the files to a new location, next change the path in the Advanced Configuration, and finally unpause it.

Not trying to nitpick, but the screenshot shows the Web GUI, just the small screen version :grinning:.

This can go to hell very quickly if some of the files are being used by other software, or are locked by the OS (which is often the case in Windows). Also, a “simple” mv can take hours or possibly days if you are dealing with giant folders and want to move them between different storage devices, etc. I would say that there are many factors to consider here.

That said, other software like Dropbox does have an option to change its location, although it stops and reverts the process if some of the files fail to move in between.

Anyhow, I would advise to check https://docs.syncthing.net/users/advanced.html. You can access the Advanced Configuration on your mobile device the same way as you do on a desktop. However, I would strongly suggest to inform yourself on each setting very well before touching any of them.

4 Likes

what are all the cases?

awesome post!

i didn’t realize even the web versions were so different among devices.

once, back in 2000, i developed a small file system using asp (not .net) which allowed for infinite nested folders… it was both cool and a nightmare. yes, i do know how coding hell looks like!

above all, indeed i don’t know in this case what’s the best way to handle path changing, and perhaps it’s better to leave as it is…

i just still can’t understand exactly why. if it’s just because of too many cases to handle, i still would miss at least a “nobody cared to send a pic request for that, and the team had other priorities” along with it.

my curiosity gets increasingly bigger to understand narrow unexpected limitations such as this on suggested that’s incredibly well done and minimalistic such as syncthing. so i hope it doesn’t look like i’m challenging it. just trying to understand it.

redundancy of intentions aside…

my first vision when i said “simplest way to handle path change” wasn’t moving files, but doing exactly what removing a folder and adding again already do: just dropping the previous “folder id” and creating a new one… except with the same id and settings intact.

i envision this should only trigger a new scan and give a warning there might be consequences on the shared devices if the folder is greatly different, as expected.

but then again, even this was probably already thought through by the Devs, perhaps even removed from a previous version. and i just wonder why.

When you maintain a project like this, that is used by quite a few people, you do not only need to think about is it possible, maintainable, useful, …, but also about how will it be broken and what are the consequences (both for the user and “us”, in terms of support). What can be broken, will be. The simplest way you proposed will be broken by users assuming their files will be moved to the new location. That’s not terrible in itself, it just means redownloading all the files. However a lot of users will consider that terrible (bandwidth, double disk usage, …) and I wouldn’t want to support that and have to explain, why we do what we do.

For most other actions and scenarios you can think of it’s the same. Or if you want to cover all the eventualities, it becomes too cumbersome.

3 Likes

it depends on how it’s done.

i picture the folder would be pause, a warning given.

users would ignore the warning and unpause the folder.

if the new folder is then empty, bandwidth issues could arise, sure. or storage, or whatever. but then users will know 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.

and again, curious to know all the cases. aren’t them somehow listed somewhere already?

I am not aware of such a list, and I am not interested in trying to do it (all the cases will be hard anyway).

Bold mine:

That clearly shows you don’t appreciate the support part I wrote about before: If every (other) user trying that feature runs into that problem, you get a lot of users to support.
If I were such a user, I’d complain: Why do you even offer that option, when effectively it does the same as removing and readding the folder? I want you to move my data.

And I am not saying this can’t be done sensibly, just that you can’t cut corners.

because it’s not the same.

it saves all the settings and shared devices connections. a lot of rework that don’t need to be done.

If I were in the mood I would now continue this discussion in “convinced user wanting to push their way mode” and let you run against a wall with (perfectly reasonable) arguments. I am not luckily :slight_smile:
Point about support still stands.

1 Like

perhaps. but you might be surprised on how support can go a different way…

users are not really always trying to break stuff, that’s just a safe mindset to have on the dev side, but which also needs to be loosen at times.

if this idea indeed wasn’t considered so far, yes, i will push for it until someone can convince me otherwise.

that’s not why i came here, though.

and thanks for tagging along! :kissing_heart: