Been using my Dropbox account for years on a Lubuntu system. Now, my new company has made a Business account available to me.
However, Dropbox insists that this folder should be called:
And there seems to be no way of changing it. I'm by no means a linux or cli expert, but one thing is renaming all my different absolute paths to something else, that's a one-time effort, but another thing is renaming it into something else with spaces. I'm foreseeing a lot of minor annoyance in my workflow if all filepaths I use suddenly includes a space by default.
So one possible way around this is to either symlink or mount --bind the ~/Dropbox (firm-name)/ as ~/Dropbox/.
This question seems to be concerning the same issue, and suggests using mount to bind the directory. by doing that, I would:
sudo mount --bind '~/Dropbox (firm-name)/' ~/Dropbox/
And then put it in /etc/fstab so it doesn't disappear when rebooting.
However, I'm basically unsure of wether that is a very bad idea that will lead to all sorts of issues. I don't understand the mount command well enough to feel comfortable using it for something so important as this without guidance.
Symlinks in dropbox have worked fine for me when placing a symlink outside dropbox pointing to a file or folder in Dropbox, but symlinks inside the Dropbox folder has led to issues in the past, that seems to have changed, however. This use-case is different, in the sense it is the entire dropbox folder that should be synced, like so:
ln -s '~/Dropbox (firm-name)' '~/Dropbox'
So I'm asking: what -if any - is a safe, reliable way of linking ~/Dropbox (firm-name)/ to ~/Dropbox/? It seems like a mount --bind or a symlink are the two best possibilites, but even though I've read about the differences, I don't know which of the two I should choose for this scenario. Is it even possible to do in a reliable way, or should I just pay up for my own account (seems so redundant though!). the symlink-way seems to have worked for this guy, but it's not a very detailed answer and I'm afraid of the unforeseen consequences and the loss of data and work.
note: It could be argued that the question I link to is the same question, but the original author never accepted the only answer. Also, there are some differences in his circumstances with a headless server, and being not an advanced user, although I've been using linux for years, I don't know if our premises are the same. I will argue less advanced users would benefit from a question and answer to this that had a very basic use-case premise.