“Dear Dropbox,” a frustrated user wrote to Dropbox, “STOP DESTROYING MY SYMBOLIC LINKS.” What does this mean? Dropbox’s handling of symlinks is fantastic for one particularly handy purpose … and rather janky for others. And it’s not easy to explain…
Handy: Symlinks to external folders
Dropbox follows or resolves symlinks by default. That is, on Dropbox servers, symlinks are replaced by the data they point to. Then you have the data in the cloud — not just a pointer.
This works wonderfully for syncing folders outside your Dropbox! It a terrific obscure feature. For instance, you can put a link to your Documents folder in your Dropbox, and it will follow the link and sync the contents of your Documents folder like a boss. On your synced computers, the symlink continues to look and act like a symlink file in Dropbox (on a Mac, for instance, it looks like an “alias”). But the entire Documents folder shows up in the cloud: Dropbox replaces the symlink with your entire Documents folder.
This is organizationally handy if you want to sync a non-Dropbox folder. Sometimes you don’t want to move a folder into Dropbox just because you’d rather have it somewhere else, or it has to be somewhere else. For instance, this method it’s critical for a folder like the Sites folder on a Mac, which has to be in a specific location to work. If you want to sync a Sites folder with Dropbox, you have no choice: you have to link to it, and Dropbox must resolve the link. Which it does.
Janky: Symlinks to internal folders
Things get weird (and bad) if you symlink to data inside your Dropbox, and you don’t want those symblinks to resolve — that is, if you need your symlinks to be symlinks, and not dumb copies of the data they point to.
Internal symlinks might appear to work out at first, depending on how you set up: you may see a link on both machine A and B, as you hope. Unfortunately, Dropbox does not support your intent, and sooner or later it’s probably going to replace your symlink with a copy of the file or folder it points to, which is pure pain. The problem is clear: on Dropbox servers, up there in the cloud, there never was any symlink to begin with. Dropbox simply doesn’t (reliably) sync pointers-as-pointers.
It’s maddeningly inconsistent though! I have internal symlinks that seem to sync just fine for quite a while. And then I have others that clearly get replaced by copies of the data they point to. In one case, in a 4-Mac scenario, two of them have synced perfectly healthy, functioning symlinks … and two have destructively replaced them with copies of the linked folders. I have some ideas what the difference is, but ultimately the details aren’t really important unless there’s some symlinks-as-symlinks configuration, which I haven’t found and probably doesn’t exist. It’s likely that this kind of setup will fail both unpredictably and silently. Even if you think you’ve got it licked for a while, chances are good you’re going to wake up one day and realize that a critical symlink has been replaced by duplicate data … which is hopelessly out of sync.
As a general rule, I’ve found that symlinks will be preserved on the originating, “donor” machine better than a recipient machine. And this seems to work to: creating identical symlinks while Dropbox isn’t looking seems to preserve them when you turn Dropbox back on, at least at first. But these aren’t exactly convenient or complete solutions.
So what to do? What if you absolutely, positively have to sync a symlink “as is”?
As far as I can tell at this time: don’t use Dropbox. There are other services that will handle symlinks differently and better for many common needs (I’ve heard that the Copy syncing service — a direct competitor — does a nice job with symlinks, for instance).
Many awesome Dropbox use cases have died for lack of this feature
Should Dropbox fix this? Can they? As of fall 2013, there is a feature request with ~2700 votes and 62 comments. My comment was, “Many awesome Dropbox use cases have died for lack of this feature.” A year ago, Andrew wrote:
STOP DESTROYING MY SYMBOLIC LINKS.
With love, Software Developers
The explanation for the situation is fairly clear, though: because the way things work right now supports linking to external folders, which is an extremely handy power-user feature. Which relies on resolving symlinks! I assume the trick isn’t so much getting Dropbox to sync links as-is, but doing so without sacrificing the external linking option.
The only general solution I can imagine would be an (advanced!) per-item setting … which is not exactly Dropbox’s style. Symlinks can be be a bit of a mindfuck on their own. Imagine how confusing things could get if some symlinks as are synced as-is, while some others resolve, and the only way to tell the state of a not-very-exposed switch in the cloud … or data loss if you get it wrong! Eep.
Update October 2014
Dropbox handling of internal symlinks seems to have gotten worse since version 2. I used to be able to get away with it. Now I can’t: no matter what I do, I end up with a lot (thousands) of bogus “conflicted” copies. I have now completely abandoned symlinking within the Dropbox folder. It’s just not worth it.
I was mostly symlinking shared source code for a variety of web development projects. I replaced that with a build process that just straight-up duplicates canonical source code to various project folders. A very boring solution, really, and not all that broadly applicable. Many symlinks are harder to live without — depends on what they are being used for.