How do symbolic links work in Dropbox?

Question

I made some links to files in a folder. When I added that folder to Dropbox, the links contained duplicate copies of the files linked to. Have you had this problem? Do you understand what is happening? Is there a solution?

To make this question clearer: In the "type" column of the file manager, before connecting to Dropbox, Link_to_notes was shown to be a link and the size was 32 bytes. After connecting to Dropbox, Link_to_notes was shown to be a plain text document and the size was 18.7 kB, the size of the notes file.

Solution 1

DropBox follows symbolic links and treats them as directories. It's really useful for backing up without having to move files and directories into your DropBox directory.

$ ln -s ~/Documents/ ~/Dropbox/Documents

or store the files in DropBox and create a symbolic link in the opposite direction

$ ln -s ~/Dropbox/Documents/ ~/Documents

Solution 2

The best way to do it is to store the files in the dropbox folder and symlink to them from outside...

So create ~/Dropbox/Documents and symlink:

ln -s ~/Dropbox/Documents ~/Documents

This stops dropbox getting confused and de-linking anything that is a link inside because you have all the things inside and instead when you want them elsewhere you link to them in dropbox. The basic rule is don't have any symlinks anywhere inside the dropbox folder...have them outside the dropbox folder and you'll have no problem.

I have dropbox on several ubuntu machines and have all my major top level folders actually stored in dropbox.

Solution 3

dropbox will follow sym links to directories, but it will break a link (either sym or hard) to a file and replace it with a file.

Solution 4

TL;DR: Below is a way to get behavior quite similar to symbolic links, at the graphical user interface (GUI) level only, which is especially helpful if you don't want DropBox repeatedly copying the same files to different folders within the DropBox hierarchy just because you want to view them from different places (i.e., folder paths).

Background

More than once I've been burned by DropBox duplicating folders if I create a symbolic links (symlinks) within the DropBox folder hierarchy, even to the point of filling my account. As many have noted around the web, there's no real fix for DropBox's lack of treating symbolic links properly, which is unfortunate as it would not be hard for them to do so.

Workaround

One workaround I use, however, to achieve the equivalent behavior of symlinks within the DropBox hierarchy --- what others often refer to as "internal symlinks" --- without DropBox duplicating everything is to create the equivalent of a Windows shortcut file (i.e., a .lnk file in the MS ecosystem). I do so by creating a .desktop file that opens my system's file manager to the desired path. Thus, this workaround only works at the GUI level and only for XDG compliant systems (e.g., Ubuntu, GNOME-based systems, many others).

Example

For example, I'm reading up on advanced Python techniques for a new job I'm taking, and the PDFs I'm reading are stored on my DropBox folder for the GoodReader App (iOS) so I can read them both at my desktop and with my mobile devices. Rather than having to drill down to that folder (/home/morse/lib/active/GoodReader/Books/Python), I simply create a Python.desktop folder under /home/morse/Desktop with the following contents:

#!/usr/bin/env xdg-open

[Desktop Entry]
Version=1.0
Type=Application
Name=Python
Exec=nautilus /home/morse/lib/active/GoodReader/Books/Python
Icon=/usr/share/icons/MacBuntu-OS/places/96/stock_folder.png
Terminal=false

(Note: Be sure to adapt the Exec=nautilus ... portion if you are using a file manager other than Nautilus, and of course you will want to adapt the Name=, Icon=, and path portion of the Exec= line for each "symlink" you wish to create.)

With this, I see a folder named Python on my desktop that acts just like a symbolic link --- that is, I double-click it and it opens the appropriate folder --- but only a small text file (e.g., Python.desktop) gets sync'd to DropBox and my other systems (as opposed to all the contents eventually being duplicated everywhere by DropBox).

As with other .desktop files, permissions must be set such that the file is both readable and executable (e.g., chmod 700 Python.desktop or chmod 755 Python.desktop) for the indicated icon to display and for double-clicking it to actually do anything.

Summary

In summary, then, I'll always have the actual files available somewhere within DropBox --- in this example, /home/morse/lib/active/GoodReader/Books/Python --- but I'll also have a desktop "shortcut" to it across all my linux-based systems for which I also have DropBox configured.

Of course, this workaround does not work at the command-line level, as a true symlink would.

That said, this does appear to be a novel workaround at the GUI level, one I've not seen posted elsewhere. So, I'm hopeful this approach can be of use to others.

View more solutions

Comments

[Sergey]

With Dropbox being a cross-platform solution, every other behavior would probably be even more confusing - how would it behave if you sync your folder with a Windows machine?

[eri0o]

Since mid 2019, Dropbox no longer follow symlinks

[Jus12]

As of current writing, symlinks no longer work, and it sucks.

[Vicon]

This could be a dangerous behavior. For example, if I delete the link from Dropbox directory, is there possibly any scenario that I could be accidentally deleting my original files or folders too?

[Gregology]

@Vicon, that's not dangerous behaviour, that's expected behaviour. But yes, to be clear, if you remove the symbolic link, the files will be removed from Dropbox too

[Gregology]

Why would Dropbox get confused? And how would Dropbox alter symbolic links? Symbolic links are automatically resolved by the file system

[Vicon]

In Dropbox community, it has been stated over and over that Dropbox does not support symbolic links and strongly advice against using it. If you contact Dropbox customer support, they will ask you to remove any symbolic link before proceeding. Sure, people can still use it, but this is not a behavior intended by Dropbox, and can be dangerous (losing files), problematic (having duplicated files unintentionally synced, which is the problem asked to be solved in this question), as well as syncing performance issues, etc.

[Gregology]

@Vicon, symbolic links operate transparently for many operations: programs that read or write to files named by a symbolic link will behave as if operating directly on the target file

[Praveen]

This is genius! I have not seen a solution for internal symlinks until now! And this is super neat. Thank you for making my day! I should add that it should be fairly straightforward to make a command-line script, which parses a .desktop file and opens the file or folder that is symlinked, though you may not be able to "cd" into the directory directly.

[pauljohn32]

This method has worked well for me for a long time in ext4 file systems. I don't have any feeling of danger because I never interact with Dropbox files within Dropbox. It succeeds to link together my Linux systems and Android tablets. However, i notice this link says my advice is out of date help.dropbox.com/installs-integrations/sync-uploads/symlinks

[Jim Balter]

@pauljohn32 Dropbox changed mid-2019 so that it now syncs symlinks as such, rather than following them, so this will no longer work.

[Jim Balter]

@Gregology stat vs. lstat

[Jim Balter]

As of mid-2019 Dropbox syncs symlinks as symlinks rather than following them, so it doesn't break them but it also doesn't sync the content of the target.

[Jim Balter]

As of mid-2019 Dropbox syncs symlinks as symlinks rather than following them, so internal links work correctly (but external links are just synced as symlinks--the content of the target isn't synced). "as it would not be hard for them to do so" -- well, there's a tradeoff for external symlinks ... many people were thankful for the change but many others were burned by it. Dropbox should have made it an option.