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.
-
Navigate to the directory the symbolic link should be created in.
cd "C:\Users\crack\Documents\[ GLOBAL ]\[ SOURCE ]\[ INITIATIVES ]\Audio\Music" -
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.
Best Answer
Three things:
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.
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.
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:
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:
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.