Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
177 lines (104 sloc) 11 KB
layout: 2013-articles
#worked: 0
date: 2012-12-14
title: Dropbox and symlinks
tags: [Dropbox]
In short: <strong>The Dropbox server does not support symlinks. All your local symlinks are followed and uploaded as plain files and folders into your Dropbox account.</strong>
<h2 id="none">No symlinks in the server</h2>
<p>In order to support old Windows machines that do not have symlinks, the Dropbox team decided to cut symlink support from all platforms.</p>
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. — <a href=";replies=85#post-164471">Rian H., Dropbox employee</a>
<p>The fact is: the Dropbox server has no support for symlinks, it only syncs files and folders.</p>
<p>Just browse your files in the Dropbox website and see it for yourself: all your symlinks were converted to plain files and folders.</p>
<h2 id="followed">Local symlinks are followed</h2>
<p>When you create a symlink inside your Dropbox folder in your computer, the syncing process will start. But instead of uploading the symlink itself, Dropbox will follow the symlink and will upload the file or folder it points to.</p>
<p>It doesn't matter if your symlink points to a file that's inside or outside your Dropbox folder. Symlinks are always followed and Dropbox always treat your symlinks as if they were plain files or folders.</p>
<p>This is the default behavior and cannot be changed.</p>
<h2 id="external">External symlinks</h2>
<p>Since symlinks are always followed, it's a common practice to use them to include external folders into your Dropbox without actually moving them there.</p>
<p>To include your Desktop folder into Dropbox, just make the <code>~/Dropbox/Desktop</code> symlink pointing to <code>~/Desktop</code>.</p>
$ ln -s ~/Desktop ~/Dropbox/Desktop
<p>Note that this practice will become obsolete when (if?) the <a href="">#1 feature request</a> Watch Any Folder is implemented.</p>
<h2 id="internal">Internal symlinks</h2>
<p>Internal symlinks are complicated. Expect problems. Avoid if possible.</p>
<p>When both the symlink and the target file reside inside your Dropbox folder, you end up with duplicated and possibly unsynchronized content.</p>
<h2 id="duplicated">Duplicated files and your quota</h2>
<!--<p>When your symlink points to a file that's already inside your Dropbox folder, you'll end up with two copies of this file in your Dropbox account. The same happens for folders.</p>-->
<p>Say you just made the symlink <code>~/Dropbox/mp3</code> pointing to your 5GB music collection folder in <code>~/Dropbox/iTunes/iTunes Media/Music/</code>. When syncing, Dropbox will follow the symlink and will upload it as a plain folder. Guess what? There goes all your music duplicated to the new <code>mp3</code> folder in your Dropbox account.</p>
<p>Dropbox is smart enough to detect that those files were already uploaded, so it will do a server-side copy and will not spend your bandwidth uploading them again. But regardless, those "new" files will eat up your account quota: now your music spends 10GB of quota.</p>
Note: Mac users who upgraded to iPhoto '11, which <a href="/articles/iphoto-symlinks.html">uses symlinks in the photo library</a>, saw their Dropbox free space disappear as their photo collection got duplicated. Fortunately, <a href="/articles/dropbox-iphoto-11.html">there's a fix</a>.
<p>To avoid the quota disaster, you can use <a href="/articles/dropbox-ignore-folder.html">a hack</a> to ignore the symlinks that point to huge folders. Or just avoid symlinks at all, if possible.</p>
<h2 id="original">Symlink here, folder there</h2>
$ cd ~/Dropbox
$ mkdir foo
$ touch foo/abc.txt
$ ln -s foo bar
<p>After Dropbox syncing:</p>
<li><code>foo</code> is a plain folder in both your machine and Dropbox server.</li>
<li><code>bar</code> is a symlink in your machine, but a plain independent folder in the server.</li>
<li><code>foo</code> and <code>bar</code> are two distinct folders in the server.</li>
<!--<li><code>foo/abc.txt</code> and <code>bar/abc.txt</code> are the same file locally, but different files in the server.</li>-->
<p>The symlink is always preserved in the original computer it was created. But in any other instance it will be a plain folder: the Dropbox website and mobile app, a new computer you install Dropbox. This discrepancy between the main machine and the server can lead to unexpected problems.</p>
<p>The symlink in the original computer is also the only thing that keeps both folders connected. If you change only one of the folders in the web interface, when the original computer syncs it will replicate the change to the other folder. If you format that computer, the connection is gone and each folder is now really independent of each other. They will become unsynchronized.</p>
Your computer is the only place "bar" will remain as a symlink. As long as this is your main machine, you should not have any problem.
In your machine everything seems fine, the symlink you created is there. But the problem is in the server: "bar" became an independent folder, with the same contents as the original "foo" folder. They are not linked in any way in the server. If you install Dropbox in a new computer, it will download both folders and no symlink.
It's important no note that the symlinks are still there in the original computer they were created. When using that computer, it doesn't matter it you edit/copy/remove files inside the original folder or inside the symlink that points to it. You're always working at the same set of files.
That's a nightmare for symlink lovers.
<h2 id="removing">Only remove symlinks in main computer</h2>
<p>Never remove, via web or mobile interface, a folder that's in fact a symlink in the original computer. Both the symlink and the original folder contents will be removed.</p>
<p>In the previous example, say you remove the <code>bar</code> folder in the web interface. It works, but when your original computer syncs this change, bad things happen. As you expect, the symlink <code>bar</code> will be removed from your computer. As you do not expect, the original folder <code>foo</code> is now empty!</p>
<p>How it happens: The procedure to remove folders is to first remove all the folder contents (files and subfolders) and then remove the empty folder. Since the Dropbox client needs to remove the "folder" <code>bar</code> from your computer, that's what it does. But here <code>bar</code> is a symlink to <code>foo</code>, the original folder, which sadly get all its contents removed. When it's empty, Dropbox finally removes <code>bar</code>.</p>
I used to share folders with other Dropbox users by creating a symlink in ~/Dropbox to the actual folder I wanted to share. If I delete the symlink, the folder is no longer shared. Fine. If the other person deletes the shared folder (not a symlink for them, also fine), then not only the symlink on ~/Dropbox gets deleted (which is reasonable), but also the files on the original folder where the symlink pointed to! This is hardly expected behaviour and could lead to serious data loss. Please change this!
— Eduardo R.
<h2 id="backup">Not a backup utility</h2>
Note that Dropbox is not a backup utility, but a file synchronization utility. We made the decision to handle symlinks transparently, so that the complete file tree would be exactly the same on all operating systems and on our servers, as presented by the file managers. — <a href=";page=3&amp;replies=85#post-172382">N.N., Dropbox forums moderator</a>
<p>Since symlinks are not preserved, avoid using Dropbox as a backup utility. All your symlinks will be lost in a restore. You'll have to manually recreate them.</p>
<h2 id="restore">Restoring the symlinks</h2>
<p>If you install Dropbox in a new machine, you will have to manually recreate all the symlinks.</p>
<li>Wait for the initial download to complete.</li>
<li>Quit Dropbox.</li>
<li>Find the symlink location and remove the duplicated file or folder.</li>
<li>Recreate the symlink to the original file or folder.</li>
<li>Repeat steps 3 and 4 for each symlink that need to be restored.</li>
<li>Launch Dropbox.</li>
<h2 id="list">Keep a list of your symlinks</h2>
<p>It's a good practice to keep an updated list of all your symlinks, so you can restore them manually in a new computer, if needed.</p>
$ find ~/Dropbox -type l -ls &gt; ~/Dropbox/symlinks.txt
<h2 id="avoid">Avoid symlinks if you can</h2>
<p>Given all these gotchas, it's better to avoid using symlinks inside your Dropbox folder until they add real support for them in the server.</p>
<h2 id="vote">Vote</h2>
<p>Use your Votebox credits to tell Dropbox you want symlink support: <a href=""></a></p>
<!--<p>Read the comments! Lots of use cases and problems.</p>-->
# Problems
Currently, having a mix of windows/linux machines AND using symlinks causes no end of woes, like duplicated content, conflicted versions, and disappearing files (especially when using a CVS/SVN/GIT checkout from a repository, which tends to add lots of files in a very short time).
# The good side of the current behavior
I agree, for symlinks that are inside the dropbox folder, it is less than ideal. However, for linking a file that cannot be moved into dropbox, symlinks need to work the way they do. I just meant symlinks are widely used to implement "watch any folder" and if just the link was synced, that wouldn't work (I know that the suggested method is move the original and put a symlink in the location of the original, but I don't like seeing the green checks outside of dropbox folder so I do it the other way)
Another case for symlinks working as they do: I wrote a program, and I share the binary with two completely different groups of people. So, I symlinked the program (which is in my Dropbox folder) into both shared folders. That way, if I ever edit the program, both shared folders get the update program without me having to think (and since it's a compiled program, I know no one will change it, which would be bad). If just the link was synced, the shared folders would get a link pointing to nowhere. And some of the people I share with use Windows systems, including XP (so no symlinks or junctions).
Basically, dropbox has to work for the lowest common denominator, which means treating links as files, not as links.