[theaino]

As another commenter mentioned, it is actually very common to symlink dotfiles like that and is how most dotfile management tools work. Dropbox’s magic symlink following has always been the anti-pattern and has made it impossible to sync symlinks properly, until now apparently.

[theon144]

> Dropbox’s magic symlink following has always been the anti-pattern

Uh, what?

Following symlinks is the default behavior for unix programs that requires extra effort to work around, why would it be "magic", or an antipattern?

[theaino]

Dropbox was replacing symlinks with the target file or directory tree in synced copies. This obviously breaks legitimate symlinks since the whole point of having the symlink is to have a reference to the target, not another copy of the target.

It’s really simple: symlinks are symlinks and should be synced as symlinks. Now they are.

[codetrotter]

In the context of file archival and synchronization.

Just like how when you tar up a directory, the symlinks are stored as symlinks, not as the files they point to.

[vinceguidry]

I stopped using symlink dotfile management when I realized that not every unix system you work on works well that way, the catalyst for this change was termux. Now I simply copy the files from Dropbox using a custom script. It replicates the utility of stow without the symlinks. Downside is I have to remember to rerun the script on all my machines whenever anything changes.

I fixed this by integrating all of personal software dev together into a singular build system that will run my sync script, which also manages the various package managers on my systems, once a day if it hasn't been run. Idempotency is my best friend.