Syncing when using symbolic links

[neilcothran]

Hello,

I am having an issue concerning dropbox syncing when using symbolic links.

Using Windows 10 and the Dropbox app, recently downloaded / installed so I believe it is fully up to date.

On the "host" machine, rather than copying (and thus duplicating) all files to the Dropbox folder, I create a symbolic link in the Dropbox folder, using the command prompt:

>mklink /d Documents C:\<path_to_real_documents_folder>

This works fine, except that when files in _real_documents_folder  are changed, they do not get "synced" on Dropbox unless I "force" it.  I click the Dropbox icon, the lower left says "Up to date" .  Hover mouse and it changes to "Pause syncing".  I click that, then it says "Syncing paused".  Click again, and it then updates and syncs the files.

The result is that, without remembering to do this, the Dropbox copy never updates, (unless exited and restarted) either by "logging on" through the web site, or on another computer using the app and same login credentials.  If I do remember to do this, everything is fine.

Is there a way to get this to happen automatically?

Thanks.

[Jay · Accepted solution]

Hi Neil, long story short, Dropbox doesn’t support symlinks and never has. 

If they do work, it is purely luck, since the majority of the time it creates performance issues, permission failures and data loss.

This article describes a little more about what symlinks could do if found in a Dropbox folder.

Hope this helps!

[neilcothran]

Hi Jay,

Many thanks for the response.

Interesting .... I've not observed any of the issues mentioned in the article your link pointed me to.  The use of symlinks seems to work quite well, except for the "update" bug I originally mentioned.  As long as I remember to "force" the re-sync, everything falls out as I wanted, giving me the ability to "carry things around" from computer to computer without all the aggravation / overhead of copying to USB's etc which ends up duplicating data and creating version control headaches.

After doing some more experimenting, I note that the problem as I've described is apparently uni-directional: Changes made on the "host" machine (the one with the symlinks in the Dropbox folder) need the "forced" update as described.  Changes from other computers as well as from the Dropbox web portal are reflected to the "host" machine vitually instantly, as long as it is online.  That accomplishes exactly what I intended: the ability to "carry work home" and voila, there it is on the office PC instantly.

So far, so good.  But, what I've done thus far is shared only with myself; I've not tried sharing amongst others, simply because thus far I've not needed to.  But I suspect that the same thing would happen.

Just My Humble Opinion, but it would perhaps be good if Dropbox could find a way to "officially" support the use of symlinks.  In the meantime, perhaps I can find some way to "trigger" the app to do the update thing.

Again, thanks for your support.

[Rich]

---

@neilcothran wrote:

The use of symlinks seems to work quite well, except for the "update" bug I originally mentioned.

---

It's not a bug. When Dropbox is installed, it registers itself with the operating system to be notified of file changes within the Dropbox folder. It doesn't sync files at the other end of a symlink in real-time because the operating system isn't notifying Dropbox of those changes (because it's outside of Dropbox). It does sync when you force it to because Dropbox then scans all of the files in the Dropbox folder for changes, and when it reaches the symlink it follows it to the other end, scans the files and detects the changes.

---

[neilcothran]

Ha, thanks, understood. It's not a bug, it's a feature! As a long-time programmer myself, I should have realized how badly I misspoke... 🙂

Would be nice if there was a "rescan all" button.. Oh well the work-around works. Just takes three clicks instead of one.

Fantastic product nonetheless!

[neilcothran]

Finally got around to making this post to update....

Ok so my thought was to have a "rescan all" button, and since we dont.....

Workaround is to stop and restart Dropbox app.  So I now have 2 icons on the desktop: one to kill Dropbox and the "normal" one to start it.

The first one has a one-line command:  taskkill.exe /f /im dropbox.exe

Double-click, wait a sec, double-click the "normal" Dropbox app.

Problem solved.

[hoanglan87]

Another update for who still have same problem:
Put the file/folder in your dropbox and make the symlink outside in the original location.

[jeff1054]

Hi Jay,

Actually they do (or at least seem to so far) if created properly. This obviously fails:

% cd ~/Dropbox ;   ln -s ~/mydir ./mydir

But if the symlink is from outside Dropbox to a file that is inside Dropbox, it seems to work fine. But only if the link is created carefully. Curiously, this fails:

% cd ~/Dropbox ;  ln -s myDropboxDir ~/mydir

And this fails:

% cd ~/Dropbox ; ln -s myDropboxDir mydir ; mv mydir ~

BUT this works:

% cd ~ ; ln -s ~/Dropbox/DropboxDir mydir

You end up with a directory (actually a soft link) ~/mydir that works perfectly well, with contents accessible on all machines using the Dropbox account.

Going end to end:

mac1> cd ~/Dropbox; mkdir myDropboxDir ; cd ~ ; ln -s Dropbox/myDropboxDir ./mydir

Makes a perfectly functional ~/mydir

And on a second machine:

mac2> cd ~ ; ln -s Dropbox/MyDropboxDir ./mydir

Makes a perfectly functional ~/mydir as well. Any changes made in ~/mydir on mac1 show up (both from Finder and from the command line) in ~/mydir on mac2. And vice versa.

Of course, Dropbox/myDropboxDir should be set to sync.

I think this effectively provides all of the functionality one might want using symbolilc links with Dropbox. For example, it provides a way to have ~/src and ~/bin synchronized across machines.

[Lusil]

Hi everyone! Thanks for keeping in touch with us on this thread regarding symlinks. 

I just wanted to note that, if you haven't already, you can check out more info about symlinks and how to use them with Dropbox in this article. 

If you have any other questions or feedback for us, feel free to give us a nudge. Thanks again!

[jeff1054]

Hey Lusil,

Thanks for the article, but it still misses the point. It discusses the differences between symbolic links inside Dropbox pointing to objects also inside Dropbox (which work) and symbolic links inside Dropbox pointing to objects outside Dropbox (which do not work).

But the article does not discuss symbolic links where the object itself is inside Dropbox but the symlink is outside Dropbox.

You do not discuss the case:

OutsideDropbox/linkdir --> Dropbox/dir

To me, the last is actually the interesting case, because it allows one to have files and directories that seem to be outside of Dropbox but in fact are shared and synced. Which is kind of the point. 

You just have to be careful about how the link is constructed. It has to be a soft link properly constructed from the command line with ln -s. (From the Finder soft links and Apple "alias" files are tagged the same way with a little arrow, but they are absolutely not the same thing. Apple alias files don't work here.)

PS: I have since realized that some of the strangeness applies to any soft links (ln -s variety) regardless of whether the target file is inside Dropbox or not. My bad. The point is that the great utility of soft links is to make a shared or remote resource look and behave as if it is local. Soft links to Dropbox items serve that purpose in spectacular fashion.

I should also say that Dropbox is a great service. I already use it in many ways; my environment and workflow would blow up without it. I'm finding new ways to put it to use routinely. Having seen comments to the effect that "symbolic links are not supported," I had never really gone down that path. I posted here because of my pleasure in discovering that when thought about and implemented with some care, Dropbox and symbolic links work together amazingly well.