File sync service supporting symbolic links

According to DropBox (https://www.dropbox.com/help/145/en)

Junction points and aliases

Dropbox will follow Windows junction points (Windows Vista or later) and sync the files or folders they link to. However, any changes to those files or folders made from the Windows operating system will not sync again until the Dropbox desktop application is restarted. To get around this, move the original folder to your Dropbox and add a junction point from its previous location to link to its new location in the Dropbox folder.

Three things:

1. don't use symbolic links unless absolutely necessary, because by default you need to be admin to use them. If you only want to link dirs locally, use Junctions, which are supported by a default restricted user as well.

2. Try to replace software which doesn't support long Unicode file names, which is possible pretty often. Those long file names are around ever since NTFS and Windows NT, so software simply should support it and many frameworks/runtimes like Java do so out of the box. Software which is intended to copy things around or back things up, which doesn't support long file names, is pretty much broken and surely has other serious limitations as well, especially in case of backups. Think of things like permissions, handling different links and file types properly, Alternate Data Streams etc. One needs to be careful.

3. The reason for your actual problem seems to be differences in symbolic links vs. Junctions or maybe differences in how the paths provided by the shell are parsed:

C:\Users\tschoening\Documents\test\target>mklink /J "[ target ]" "../src/{[ murks ]}"

Verbindung erstellt für [ target ] <<===>> ../src/{[ murks ]}

C:\Users\tschoening\Documents\test\target>cd "[ target ]"

C:\Users\tschoening\Documents\test\target[ target ]>cd ..

C:\Users\tschoening\Documents\test\target>

As you can see, accessing "[ target ]" this way works, while the following doesn't and generates the same error like you have, only in German:

C:\Users\tschoening\Documents\test\target>mklink /D "[ target ]" "../src/{[ murks ]}"

symbolische Verknüpfung erstellt für [ target ] <<===>> ../src/{[ murks ]}

C:\Users\tschoening\Documents\test\target>cd "[ target ]"

Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.

C:\Users\tschoening\Documents\test\target>

At least I don't see any other difference than /J vs. /D in my test, but I might be missing something of course. So I suggest repeating your test using Junctions yourself.

Some additional interesting thing I just recognized: Opening the created symlink with the above syntax in cmd.exe and Windows Explorer directly fails, but it succeeds in Link Shell Extension. Have a look at the following screenshot, which is showing the relative path. Clicking "Ziel öffnen" opens a new Windows Explorer folder showing the link target. Looks like Link Shell Extension is interpreting / itself and might provide \ to the underlying Windows API? Something which Windows itself isn't doing, but simply using / as are stated in the link itself, which is wrong for paths. So as @Seth already recognized, the / itself is the problem with the symlinks.