Create a relative symbolic link in Windows 10 for file copies

Question

I'm going to drastically simplify everything I have tried. For exact details, please review the CMD screenshot.

I want to create a RELATIVE PATH symbolic link named [ RESOURCES ] at the following path:

C:\Users\crack\Documents\[ GLOBAL ]\[ SOURCE ]\[ INITIATIVES ]\Audio\Music 

That should point to:

C:\Users\crack\Documents\[ GLOBAL ]\[ SOURCE ]\{[ LONGCHAR REDIRECT ]}

I have been trying mklink /D in cmd as admin, with the following steps.

1. Navigate to the directory the symbolic link should be created in.

   cd "C:\Users\crack\Documents\[ GLOBAL ]\[ SOURCE ]\[ INITIATIVES ]\Audio\Music"
   

2. Create the symbolic link.

   mklink /d "[ RESOURCES ]" "../../../{[ LONGCHAR REDIRECT ]}"
   symbolic link created for [ RESOURCES ] <<===>> ../../../{[ LONGCHAR REDIRECT ]}
   

To the BEST of my understanding, this syntax SHOULD set the link to {[ LONGCHAR REDIRECT ]} in [ SOURCE ] relative to Music but it doesn't!

The confirmation indicates that the link was created successfully but when I try access the symbolic link I get the following error:

cd "C:\Users\crack\Documents\[ GLOBAL ]\[ SOURCE ]\[ INITIATIVES ]\Audio\Music\[ RESOURCES ]"
C:\Users\crack\Documents\[ GLOBAL ]\[ SOURCE ]\[ INITIATIVES ]\Audio\Music\[ RESOURCES ] is not accessible.  

The filename, directory name, or volume label syntax is incorrect.

Am I misunderstanding the use of .. to indicate a parent directory? Again, please feel free to review my multiple experiments via the CMD screenshot. I've tried multiple variations on the relative file path theme, using .., ., and changing around the current directory.

If mklink will not implement the desired association, please also feel free to recommend a relative file path alternative. I copy the [ GLOBAL ] directory to various drives and backup services, so I need the file-paths truncated to beneath the 260 MAX_PATH limitation via their actual location in the {[ LONGCHAR REDIRECT ]} folder to be reflected across each duplicate location, but I need my working directory to include their virtual locations in the [ RESOURCES ] folder.

Answer 1

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.

Answer 2

You're using the wrong kind of slashes if you want to refer to a parent from the current directory. In that case you need to use a Backslash. Forward slashes work if you only want to reference to children. With an absolute path it doesn't seem to matter.

mkdir C:\temp\example\a
mkdir C:\temp\example\b\c
mklink /D C:\temp\example\a\redirection ..\b

As for the 260 character limit, use an application that handles it instead of looking for an easily broken workaround or shorten your paths.

Answer 3

Firstly, we should look at the syntax of options and required parameters generated by entering the mklink command help request, mklink /?:

MKLINK [[/D] | [/H] | [/J]] Link Target

    /D      Creates a directory symbolic link.  Default is a file
            symbolic link.
    /H      Creates a hard link instead of a symbolic link.
    /J      Creates a Directory Junction.
    Link    Specifies the new symbolic link name.
    Target  Specifies the path (relative or absolute) that the new link
            refers to.

Currently, it is only possible to imbue relative filepath data within directory symbolic links.

Therefore, we must use the mklink command in conjunction with the ("soft link") mklink command option, /D, like so.

mklink /D . . .

The mklink Target parameter must describe a filepath that includes at least one RELATIVE FILEPATH OPERATOR such as . or .. in conjunction with as many BACKSLASHES (\) as necessitated by the relative hierarchy of (grand-, great-grand-, etc.)parent directories, as well as a "DOUBLE-QUOTED" filepath in any case where one or more whitespace characters are required by a child ABSOLUTE filepath fragment of the link's to-be-concatenated relative mklink Target filepath.

To wit, finishing the command

mklink /D "C:/Test Folder/Link Name With Spaces" . . .

by substituting the mklink Target parameter with

. . . ..\"Target Name With Spaces"

or

. . . "..\Target Name With Spaces"

will create a successfully-concatenated relative filepath target within a link generated at

C:/test foldEr/Link Name With Spaces

and finishing

mklink /D "C:/Test Folder/Test Folder 2/Link Name With Spaces" . . .

with

. . . "..\..\Target Name With Spaces"

or

. . . ..\..\"Target Name With Spaces"

will create a link at

C:/Test Folder/Test Folder 2/Link Name With Spaces.

In all four cases, the final result is a directory symbolic link that points to the directory

C:/TaRget nAme WitH SpacEs,

but which will point to a different location entirely if any of the generated links are ever moved to another directory either by a command such as robocopy or by an application which similarly honors symbolic links.