6 ms·

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

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.

Nevermindmine 7y ago
Why solution in quotes?
amelius 7y ago
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.
- chongli 7y ago
  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.
heinrichhartman 7y ago
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.
- kccqzy 7y ago
  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.
theaino 7y ago
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.
- vinceguidry 7y ago
  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.
- theon144 7y ago
  > 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?
  - codetrotter 7y ago
    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.
  - theaino 7y ago
    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.
lioeters 7y ago
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.
- theaino 7y ago
  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.
  - michaelmrose 7y ago
    I'm not saying your wrong but I don't quite understand your answer can you please expand on that?
    - Veen 7y ago
      Dropbox didn’t sync the symlinks; it synced the files that were being linked to, which is not what happens with most unix tools.
- jimmaswell 7y ago
  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.
hiccuphippo 7y ago
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.
oconnor663 7y ago
> 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?
- Erlich_Bachman 7y ago
  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.
- PunksATawnyFill 7y ago
  Dropbox doesn't care about its users. Have you ever had them lose gigabytes of your files? I have. Several days went by with not a peep after I reported that my client's files had disappeared. And I was a paying customer. Meanwhile, I signed up for Google Drive and re-uploaded all of them within hours, after Dropbox took a full day for the same upload. A year later, Dropbox still hadn't provided an explanation for the files' disappearance. They suck.

Nevermindmine 7y ago

Why solution in quotes?

amelius 7y ago

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.

chongli 7y ago
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.

heinrichhartman 7y ago

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.

kccqzy 7y ago
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.

theaino 7y ago

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.

vinceguidry 7y ago
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.
theon144 7y ago
> 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?
- codetrotter 7y ago
  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.
- theaino 7y ago
  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.

lioeters 7y ago

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.

theaino 7y ago
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.
- michaelmrose 7y ago
  I'm not saying your wrong but I don't quite understand your answer can you please expand on that?
  - Veen 7y ago
    Dropbox didn’t sync the symlinks; it synced the files that were being linked to, which is not what happens with most unix tools.
jimmaswell 7y ago
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.

hiccuphippo 7y ago

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.

oconnor663 7y ago

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

Erlich_Bachman 7y ago
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.
PunksATawnyFill 7y ago
Dropbox doesn't care about its users. Have you ever had them lose gigabytes of your files? I have. Several days went by with not a peep after I reported that my client's files had disappeared. And I was a paying customer. Meanwhile, I signed up for Google Drive and re-uploaded all of them within hours, after Dropbox took a full day for the same upload. A year later, Dropbox still hadn't provided an explanation for the files' disappearance. They suck.