12 ms·

I see multiple comments here saying that this is unfortunate because people were using symlinks in order to automatically have backups of program configurations

I see multiple comments here saying that this is unfortunate because people were using symlinks in order to automatically have backups of program configurations etc. But the solution is simple, just switch around which is the real file and which is the symlink. So where you used to have symlinks like ~/Dropbox/.bashrc -> ~/.bashrc ~/Dropbox/.vim —> ~/.vim/ and so on, remove the old symlinks and place the real files in ~/Dropbox/ and then symlink the other locations there. ~/.bashrc -> ~/Dropbox/.bashrc ~/.vim -> ~/Dropbox/.vim/ and so on. This is similar to what I do with some of my files in ~/bin/ Many of the files I have in my ~/bin/ are symlinks to files that live in git repositories. For example, I have a few “alias commands” (shell scripts that wrap a longer command) in ~/bin/ ~/bin/st -> ../src/github.com/ctsrc/shell-command-aliases/bin/st (Aside: Why not aliases in my bashrc, you ask? Because I use a few different operating systems and eventually realized that rather than trying to unify OS specifics and shared aliases in bashrc it was much simpler to maintain the aliases as wrapping shell scripts.)

Erlich_Bachman 7y ago
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.
kuschku 7y ago
This also does not work, because many programs refuse to follow symlinks for their configs (e.g. pulseaudio) Also, you might want to avoid using suckless software: https://twitter.com/kuschku/status/1156488420413362177 https://twitter.com/kuschku/status/1156488420413362177
- TeMPOraL 7y ago
  These programs are then broken, IMO. A non-filesystem-tool program shouldn't break the filesystem abstraction for no good reason. Being able to symlink configs or binaries is an important feature.
  - goblin89 7y ago
    Symlinking configuration files is the approach behind GNU stow. I version my dotfiles in a repository, and on a new system it’s enough to simply run: cd ~ git clone <dotfiles repo> cd <dotfiles repo> stow <profile|vim|ansible|bin|...> Every piece of software I use plays well with it. If I were using Dropbox, the announced change wouldn’t break my workflow.
  - y0y 7y ago
    Sounds like that should apply to Dropbox, as well.
    - TeMPOraL 7y ago
      Syncing tools are tricky because they bridge and overlap (at least) two filesystems - local and remote. It's not obvious how to handle symlinks there in general case. The default behavior dictated by filesystem abstraction is wrong (would duplicate files and break links). There are multiple other ways to handle it, but it's not clear what's best.
      - cowsandmilk 7y ago
        Explain what was wrong with Dropbox’s previous behavior (which is described in the link).
huhtenberg 7y ago
This wedges Dropbox in as a critical system dependency. Dropbox screws up - and you no longer have your core config files needed for basic system operation.
- chongli 7y ago
  If the old setup had been maintained, it still would've been possible for Dropbox to screw up by following the symlinks and deleting files all over your filesystem.
- jumbopapa 7y ago
  I think it's unlikely that Dropbox files would just disappear from the disk. They might not update, but that's the only realistic option.
  - dasil003 7y ago
    It's not realistic that a distributed and potentially shared file syncing product could erroneously delete a file?
    - rvnx 7y ago
      It's a company that allowed anyone in production to login and download/delete files of any account without any password. I'm sure they have improved procedures since right ?
  - prepend 7y ago
    I had this expectation too. Recently I started trying to use OneDrive. I had really basic expectations. But I’ve run into situations where multiple locations syncing the same files led to weird stuff. Scenario- win7, win10, mac, phone had a folder called “admin” with multiple sub folders. Turning off syncing on a sub folder on one of these ended up deleting the folder and all it’s contents on all the machines. Renaming or moving folders has also resulted in unexpected deletes. OneDrive is not Dropbox, but it reminded me not to do this with important files regardless that Dropbox has been pretty solid for 10+ years. I’m back to rsync from “source” and not using OneDrive for workflow.
thenickperson 7y ago
FYI this is easier to do with GNU stow, which can take a directory of configs and symlink it to another directory (like $HOME).
topologistics 7y ago
This seems dangerous and gives me the heebie jeebies, but I can't put my finger on exactly why. It just feels like bad practice to move my important files somewhere else and link to them, but I've never trusted the cloud anyway. It is in the nature of clouds that they change and sometimes go away. I don't want my .bashrc going away.
- maxnoe 7y ago
  That is the principle of gnu stow, which I use together with git to handle all my important config files.
- xvector 7y ago
  It’s a bad idea because you’re adjusting your whole system simply for Dropbox.
  - acdha 7y ago
    You’re letting your emotions about Dropbox color this: if you think of Dropbox as a version control system, it’s something with decades of precedent to have symlinks pointing to a checkout.
  - theaino 7y ago
    No, previously you were relying on a magic Dropbox hack that broke symlinks, whereas now the file system can be used properly and symlinks work like actual symlinks.
- dx87 7y ago
  Since dropbox keeps the synced config files on your computer, the only issue you would run into is if you accidentally delete the files on one computer and dropbox deletes the files off all of your other computers. I've been using Borg to backup my files for a while now, and it treats symlinks the same way dropbox does after this most recent change. Having my .bashrc be a simlink that points to another file hasn't been an issue.
netsec_burn 7y ago
Why not use a hardlink?
- nemetroid 7y ago
  Vim (and I believe most text editors) save files by doing (simplified): rename("myfile", "backup_file") openat(AT_FDCWD, "myfile", O_WRONLY|O_CREAT, 0644) unlink("backup_file") I.e. unlink the old file and create a new one by the same name (with a backup step in between). So the other hard link would keep pointing to the old version of the file.
  - graywh 7y ago
    What version of Vim? Because I've never experienced this problem in over a decade of use. Try it yourself: echo "test1" > test1 ln test1 test2 vim -c 's/1/2/' -c x test2 cat test1 Edit: Oh, you can configure Vim to break hardlinks https://vim.fandom.com/wiki/Editing_a_hard_link_to_a_file https://vim.fandom.com/wiki/Editing_a_hard_link_to_a_file
    - nemetroid 7y ago
      Sorry, you're right. Sadly I cannot edit my comment since too long time has passed. I should of course tested with an added hard link. Vim does do the rename/unlink if there only is a single hard link to a file, which makes inotify behave different than expected, so my guess was that Vim would also be OK with breaking hard links. But it makes sense that it wouldn't, since hard links are a much more integral part of Unix. $ echo 1 > test1 $ inotifywait --quiet --monitor test1 & [1] 14321 $ vim -c 's/1/2/' -c x test1 $ cat test1 2 $ <no output from inotifywait> With multiple hard links, the inode is preserved (only difference is adding the call to ln): $ echo 1 > test1 $ ln test1 test2 $ inotifywait --quiet --monitor test1 & [1] 14361 $ vim -c 's/1/2/' -c x test1 $ cat test1 2 test1 OPEN test1 ACCESS test1 CLOSE_NOWRITE,CLOSE $
yoz-y 7y ago
This is what I did for my tmux, vim and zsh configuration. As an added benefit it makes it easier to sync configs between computers. On work computers I do the same but with git.
the8472 7y ago
depending on how dropbox works bind mounts and hardlinks might also work.
- kijin 7y ago
  Bind mounts would be perfect, but I wouldn't count on Dropbox handling mountpoints inside the Dropbox folder gracefully in the long term. Remember when they stopped supporting all Linux filesystems other than ext4, a policy that they only recently rescinded?
tommymachine 7y ago
This should be sarcastic, but it seems like it’s not. “Just move your system files to Dropbox, and replace them with symlinks!” Sheesh!
ashelmire 7y ago
Why not create a dotfiles repo instead and keep it on GitHub? That’s what I do.
- sethammons 7y ago
  I used to do that, but it required me to run git commands to back things up. With a symlink, I don't have to think about it or set up any automation.
hsbaut76 7y ago
Use a git bare repository, it works really well for this purpose.
- yjftsjthsd-h 7y ago
  In Dropbox? Doesn't Dropbox mangle git repos?
  - hsbaut76 7y ago
    No I mean, rather than using Dropbox for dotfiles, use a bare git repo to manage them
Spooky23 7y ago
The problem lies where you have constrained space on a system, and you want a folder on an external or alternative drive.
cstejerean 7y ago
This is what I’ve always done, I didn’t even know that the other way was an option, and honestly I don’t like the idea of Dropbox reaching out of it’s sandbox at ~/Dropbox to read or write files by following symlinks. That sounds like a security risk to me.
aleem 7y ago
This is probably the desired effect that Dropbox wanted. There is little reason to remove the symlink feature that worked perfectly well - it is a strategic move at best. Reversing the symlinks means Dropbox becomes the source of truth and the dependency on Dropbox increases. Personally, I used this to easily backup my Downloads and Documents. They just broke all clients using this feature.
- ehsankia 7y ago
  Yep, they've been removing features and handicapping non-premium, while simultaneously ramping up their Premium upgrade notifications for almost a year now.
Someone 7y ago
/.bashrc -> ~/Dropbox/.bashrc ~/.vim -> ~/Dropbox/.vim/ That works for directories, but not for files such as ~/.bashprofile, if tools update such files by - writing the updated file under a different name - deleting the old file - renaming the updated file as the second step would delete the link (or fail; I’m not too familiar with the UNIX APIs) (I think that’s a fairly common strategy. I tried checking whether vim uses it, but got lost in https://github.com/vim/vim/blob/master/src/fileio.c; https://github.com/vim/vim/blob/master/src/fileio.c; that file is too large to comfortably read on an iPad (try guessing how many lines of C it takes to ”Read lines from file "fname" into the buffer after line "from"”)
- codetrotter 7y ago
  I’ve used symlinked bashrc and other files and edited them with Vim through their symlinks and never had the sorts of problem you theorized about. I would consider the behavior you outline to be an editor bug. Symlinks are pretty important and any editor that would destroy a symlink and replace it with a regular file is clearly misbehaving software IMO.
AtomicOrbital 7y ago
this is the correct solution ... its also what I have been using forever ... when I reformat a new laptop and launch Dropbox after it finishes a full sync I copy a file out of its dir which I execute on my local laptop which automates defining symlinks on my local filesystem pointing into Dropbox ... it just makes no sense to symlink out of Dropbox into the wild and wooly world at large ... symlinks should point into Dropbox not out

Erlich_Bachman 7y ago

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.

kuschku 7y ago

This also does not work, because many programs refuse to follow symlinks for their configs (e.g. pulseaudio) Also, you might want to avoid using suckless software: https://twitter.com/kuschku/status/1156488420413362177 https://twitter.com/kuschku/status/1156488420413362177

TeMPOraL 7y ago
These programs are then broken, IMO. A non-filesystem-tool program shouldn't break the filesystem abstraction for no good reason. Being able to symlink configs or binaries is an important feature.
- goblin89 7y ago
  Symlinking configuration files is the approach behind GNU stow. I version my dotfiles in a repository, and on a new system it’s enough to simply run: cd ~ git clone <dotfiles repo> cd <dotfiles repo> stow <profile|vim|ansible|bin|...> Every piece of software I use plays well with it. If I were using Dropbox, the announced change wouldn’t break my workflow.
- y0y 7y ago
  Sounds like that should apply to Dropbox, as well.
  - TeMPOraL 7y ago
    Syncing tools are tricky because they bridge and overlap (at least) two filesystems - local and remote. It's not obvious how to handle symlinks there in general case. The default behavior dictated by filesystem abstraction is wrong (would duplicate files and break links). There are multiple other ways to handle it, but it's not clear what's best.
    - cowsandmilk 7y ago
      Explain what was wrong with Dropbox’s previous behavior (which is described in the link).

huhtenberg 7y ago

This wedges Dropbox in as a critical system dependency. Dropbox screws up - and you no longer have your core config files needed for basic system operation.

chongli 7y ago
If the old setup had been maintained, it still would've been possible for Dropbox to screw up by following the symlinks and deleting files all over your filesystem.
jumbopapa 7y ago
I think it's unlikely that Dropbox files would just disappear from the disk. They might not update, but that's the only realistic option.
- dasil003 7y ago
  It's not realistic that a distributed and potentially shared file syncing product could erroneously delete a file?
  - rvnx 7y ago
    It's a company that allowed anyone in production to login and download/delete files of any account without any password. I'm sure they have improved procedures since right ?
- prepend 7y ago
  I had this expectation too. Recently I started trying to use OneDrive. I had really basic expectations. But I’ve run into situations where multiple locations syncing the same files led to weird stuff. Scenario- win7, win10, mac, phone had a folder called “admin” with multiple sub folders. Turning off syncing on a sub folder on one of these ended up deleting the folder and all it’s contents on all the machines. Renaming or moving folders has also resulted in unexpected deletes. OneDrive is not Dropbox, but it reminded me not to do this with important files regardless that Dropbox has been pretty solid for 10+ years. I’m back to rsync from “source” and not using OneDrive for workflow.

thenickperson 7y ago

FYI this is easier to do with GNU stow, which can take a directory of configs and symlink it to another directory (like $HOME).

topologistics 7y ago

This seems dangerous and gives me the heebie jeebies, but I can't put my finger on exactly why. It just feels like bad practice to move my important files somewhere else and link to them, but I've never trusted the cloud anyway. It is in the nature of clouds that they change and sometimes go away. I don't want my .bashrc going away.

maxnoe 7y ago
That is the principle of gnu stow, which I use together with git to handle all my important config files.
xvector 7y ago
It’s a bad idea because you’re adjusting your whole system simply for Dropbox.
- acdha 7y ago
  You’re letting your emotions about Dropbox color this: if you think of Dropbox as a version control system, it’s something with decades of precedent to have symlinks pointing to a checkout.
- theaino 7y ago
  No, previously you were relying on a magic Dropbox hack that broke symlinks, whereas now the file system can be used properly and symlinks work like actual symlinks.
dx87 7y ago
Since dropbox keeps the synced config files on your computer, the only issue you would run into is if you accidentally delete the files on one computer and dropbox deletes the files off all of your other computers. I've been using Borg to backup my files for a while now, and it treats symlinks the same way dropbox does after this most recent change. Having my .bashrc be a simlink that points to another file hasn't been an issue.

netsec_burn 7y ago

Why not use a hardlink?

nemetroid 7y ago
Vim (and I believe most text editors) save files by doing (simplified): rename("myfile", "backup_file") openat(AT_FDCWD, "myfile", O_WRONLY|O_CREAT, 0644) unlink("backup_file") I.e. unlink the old file and create a new one by the same name (with a backup step in between). So the other hard link would keep pointing to the old version of the file.
- graywh 7y ago
  What version of Vim? Because I've never experienced this problem in over a decade of use. Try it yourself: echo "test1" > test1 ln test1 test2 vim -c 's/1/2/' -c x test2 cat test1 Edit: Oh, you can configure Vim to break hardlinks https://vim.fandom.com/wiki/Editing_a_hard_link_to_a_file https://vim.fandom.com/wiki/Editing_a_hard_link_to_a_file
  - nemetroid 7y ago
    Sorry, you're right. Sadly I cannot edit my comment since too long time has passed. I should of course tested with an added hard link. Vim does do the rename/unlink if there only is a single hard link to a file, which makes inotify behave different than expected, so my guess was that Vim would also be OK with breaking hard links. But it makes sense that it wouldn't, since hard links are a much more integral part of Unix. $ echo 1 > test1 $ inotifywait --quiet --monitor test1 & [1] 14321 $ vim -c 's/1/2/' -c x test1 $ cat test1 2 $ <no output from inotifywait> With multiple hard links, the inode is preserved (only difference is adding the call to ln): $ echo 1 > test1 $ ln test1 test2 $ inotifywait --quiet --monitor test1 & [1] 14361 $ vim -c 's/1/2/' -c x test1 $ cat test1 2 test1 OPEN test1 ACCESS test1 CLOSE_NOWRITE,CLOSE $

yoz-y 7y ago

This is what I did for my tmux, vim and zsh configuration. As an added benefit it makes it easier to sync configs between computers. On work computers I do the same but with git.

the8472 7y ago

depending on how dropbox works bind mounts and hardlinks might also work.

kijin 7y ago
Bind mounts would be perfect, but I wouldn't count on Dropbox handling mountpoints inside the Dropbox folder gracefully in the long term. Remember when they stopped supporting all Linux filesystems other than ext4, a policy that they only recently rescinded?

tommymachine 7y ago

This should be sarcastic, but it seems like it’s not. “Just move your system files to Dropbox, and replace them with symlinks!” Sheesh!

ashelmire 7y ago

Why not create a dotfiles repo instead and keep it on GitHub? That’s what I do.

sethammons 7y ago
I used to do that, but it required me to run git commands to back things up. With a symlink, I don't have to think about it or set up any automation.

hsbaut76 7y ago

Use a git bare repository, it works really well for this purpose.

yjftsjthsd-h 7y ago
In Dropbox? Doesn't Dropbox mangle git repos?
- hsbaut76 7y ago
  No I mean, rather than using Dropbox for dotfiles, use a bare git repo to manage them

Spooky23 7y ago

The problem lies where you have constrained space on a system, and you want a folder on an external or alternative drive.

cstejerean 7y ago

This is what I’ve always done, I didn’t even know that the other way was an option, and honestly I don’t like the idea of Dropbox reaching out of it’s sandbox at ~/Dropbox to read or write files by following symlinks. That sounds like a security risk to me.

aleem 7y ago

This is probably the desired effect that Dropbox wanted. There is little reason to remove the symlink feature that worked perfectly well - it is a strategic move at best. Reversing the symlinks means Dropbox becomes the source of truth and the dependency on Dropbox increases. Personally, I used this to easily backup my Downloads and Documents. They just broke all clients using this feature.

ehsankia 7y ago
Yep, they've been removing features and handicapping non-premium, while simultaneously ramping up their Premium upgrade notifications for almost a year now.

Someone 7y ago

/.bashrc -> ~/Dropbox/.bashrc ~/.vim -> ~/Dropbox/.vim/ That works for directories, but not for files such as ~/.bashprofile, if tools update such files by - writing the updated file under a different name - deleting the old file - renaming the updated file as the second step would delete the link (or fail; I’m not too familiar with the UNIX APIs) (I think that’s a fairly common strategy. I tried checking whether vim uses it, but got lost in https://github.com/vim/vim/blob/master/src/fileio.c; https://github.com/vim/vim/blob/master/src/fileio.c; that file is too large to comfortably read on an iPad (try guessing how many lines of C it takes to ”Read lines from file "fname" into the buffer after line "from"”)

codetrotter 7y ago
I’ve used symlinked bashrc and other files and edited them with Vim through their symlinks and never had the sorts of problem you theorized about. I would consider the behavior you outline to be an editor bug. Symlinks are pretty important and any editor that would destroy a symlink and replace it with a regular file is clearly misbehaving software IMO.

AtomicOrbital 7y ago

this is the correct solution ... its also what I have been using forever ... when I reformat a new laptop and launch Dropbox after it finishes a full sync I copy a file out of its dir which I execute on my local laptop which automates defining symlinks on my local filesystem pointing into Dropbox ... it just makes no sense to symlink out of Dropbox into the wild and wooly world at large ... symlinks should point into Dropbox not out