All the docs I found online (eg: https://ss64.com/nt/mklink.html, https://stackoverflow.com/questions/9042542/what-is-the-difference-between-ntfs-junction-points-and-symbolic-links etc) mention that mklink /J
cannot be used for files, and must use absolute paths; however this seems to work (I tried this via cmd.exe on windows 10 via parallels on osx):
cat z2.txt
abc
mklink /J z2c.txt z2.txt
Junction created for z2c.txt <<===>> z2.txt
dir
...
01/30/2021 12:59 PM <JUNCTION> z2c.txt (C:Userstimotheetmpfooz2.txt)
cat z2c.txt
abc
rm z2.txt
cat z2c.txt
cat: z2c.txt: No such file or directory
this seems to show that z2c.txt
created via mklink /J
acts more like a symbolic link rather than a directory junction (eg: https://cects.com/overview-to-understanding-hard-links-junction-points-and-symbolic-links-in-windows/ mentions If the target is deleted, its content is still available through the hard link
).
Note that on explorer, z2c.txt shows as a directory link and opening it via explorer doesn’t work (gives: The directory name is invalid
), but it does seem to work on cmd.exe.
The docs seem to contradict what I’m observing, and it looks like mklink /J
can be used to circumvent the restriction on creating symlinks (must be admin or developper mode plus set SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE
). Or it could also mean that some programs (cat
) treat such links differently from others, in which case I’d like to know which programs understand such links.