Dropbox does not support symlinks, which has a nice side benefit but mostly sucks

“Dear Dropbox,” a frustrated user wrote to Dropbox long ago, “STOP DESTROYING MY SYMBOLIC LINKS.” What does this mean? Dropbox’s handling of symlinks is fantastic feature for one common purpose … but a janky, data-wrecking horror show otherwise. And has been for many years now. And it’s not easy to explain…

Dorkometer: 6/10

Originally published Sep 29, 2013. Updated Apr 30, 2018. Yes, Dropbox is still doing things this way. It’s unlikely to change.

Handy: Symlinks to folders outside Dropbox

Dropbox resolves symbolic links (symlinks, soft link) by default. On Dropbox servers, symlinks are completely replaced by the data they point to, so that you have the actual data in the cloud — not just a pointer to it.

This works great for syncing folders outside your Dropbox! It is an obscure feature-not-a-bug. 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 in the cloud, the wholes Docs folder shows up in place of the symlink.

This is organizationally super 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. 1

Janky: Symlinks to folders inside Dropbox

Things get weird (and bad) if you create a symlink in your Dropbox to data in your Dropbox — “internal” symlinks — and you don’t want those symlinks to resolve. That is, if you need your symlinks to be symlinks, and not just dumb copies of the data they point to. This has been the case for many years now, and probably always will.

Internal symlinks might seem to work out at first, depending on how you are set up: you might see a symlink on both device A and B, as you hope.

But Dropbox does not support your intent, and sooner or later it’s 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 sync pointers-as-pointers.

Inconsistent but inevitable

The destruction of symlinks by Dropbox has been surprisingly inconsistent for me. 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.2

But symlink destruction is inevitable, and it will happen silently. Even if you think you’ve got it licked for a while, you’re going to wake up one day and realize that a critical symlink has been replaced by duplicate data … which is also hopelessly out of sync.

So what to do? What if you absolutely, positively have to sync a symlink “as is”?

Don’t use Dropbox. There may be other services that will handle symlinks differently and better for many common needs.

Many awesome Dropbox use cases have died for lack of this feature

Should Dropbox fix this? Can they? As of fall 2013, there was a feature request (now defunct, though you can still find references to it) with ~2700 votes and 62 comments. My comment was, “Many awesome Dropbox use cases have died for lack of this feature.” In 2012, Andrew wrote:

Dear Dropbox,

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 selected others resolve, and the only way to tell was the state of a switch in the cloud … or data loss if you get it wrong! Eep.

Why, Dropbox, why?

I found this explanation quoted by Aurelio Jargas in 2012:

Unfortunately this is a design decision that we made a very long time ago. There is no notion of symlinks in the Dropbox system (Windows XP didn't support symlinks) so our solution was to sync all the data within symlinks as if they were actual folders anyway. — Rian H., Dropbox employee

In addition to the fact that resolving symlinks has a major side benefit, that’s probably the main, original reason for the design. Thanks a bunch, Windows XP! Still fucking with us, for 17 years and counting…


  1. 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. 

  2. In one case, in a 4-Mac scenario, two of them have synced 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 that actually works, which there probably isn’t. I haven’t found and no one has reported to me in the many years this article has been getting a fair bit of traffic.