Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


> 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?


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.


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.


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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: