Hacker News Reader

Comment by Erlich_Bachman | Hacker News Reader

This is not a "solution", this is at best a workaround. Moving around important system files and replacing them with symlinks means you are changing your system and everything in it just because one small program that doesn't want to play by the rules can do what it wants.

The real solution is to use other software than Dropbox, that plays by the rules and cares about its users.

View on HN

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.

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.

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

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.

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.

Perhaps a better solution is to use cron to rsync the system files to somewhere in your Dropbox tree. That at least gives you a one-way backup of these files. And you probably don't want to write these files in the other direction.

If you're going to use rsync anyway, you might as well ditch Dropbox and switch to a backup service that lets you rsync directly to the server. Using rsync locally into your own Dropbox folder means keeping two copies of everything, a practice that may be space-prohibitive.

Very much in agreement with your comment.

Having system files in Dropbox as the source of truth, and symlinking to their canonical locations, is a poor workaround. Does the software work for you, or do you work for the software?

As another comment suggested, one can use cron and rsync to the Dropbox folder. This at least maintains the priority of the system files being where they should be.

Or, one can use any other software that respects and works for the user. Syncthing is great.

Dropbox’s following of symlinks has always been magical, nonstandard behavior that breaks symlinks and is user-hostile for anyone who relies on proper symlink behavior.

I'm not saying your wrong but I don't quite understand your answer can you please expand on that?

Dropbox didn’t sync the symlinks; it synced the files that were being linked to, which is not what happens with most unix tools.

Dropbox as a source of truth is the pattern I was already using because it makes more sense to me. Not sure what the point of the change was though.

It's actually not an anti-pattern, to symlic files to their install locations. It's quite common to install executables to custom locations like `/opt/$company/bin` or `/opt/$appname/bin` and only symlink to /local/bin, ~/bin, etc.

GNU Stow (already mentioned here) and NIX are examples.

Executables are easy. You don't even need symlinks. Just a wrapper script that does an exec. What's harder is stuff that's not executable like configuration files. Here you have to use symlinks.

> cares about its users

This sort of snark is unnecessary. Everything has tradeoffs. Have you ever had someone accuse you of not caring about your users? Do you know how it sounds from the other end?

Yes, I do and that is why I am very careful when using such an expression. I understand that this language should be used for extreme cases. Software and it's use cases can be complex and in some situations it is hard to see what is right and what is not.

This is exactly why I used this language in this case: because it is just so blatanly obvious that this change is something they have done for whatever other reason (perhaps to make their life easier?), but not to care about its users. This is not even a new feature, this is something that has already worked and a lot of users were depending on. They are literally breaking many setups and are forcing the users to expend time and resources to immediately (was there even a warning) come up with other solutions and re-create their configuration.

I think that if they cared even a little bit, with whatever other reasons they had for this change, they could easily make it an option with a sane default, instead of a locked functionality.

I do the same but with git instead of Dropbox. But maybe the "solution" should be to use hardlinks instead of symlinks. I still prefer symli ks because I can see easily they are links.

Why solution in quotes?

Reply on news.ycombinator.com