我在网上找到的所有文档（例如：https://ss64.com/nt/mklink.html，https://stackoverflow.com/questions/9042542/ntfs-junction-points-and-symbolic-links 之间有什么区别等）提到mklink /J不能用于文件，并且必须使用绝对路径；但是这似乎有效（我在 Windows 10 上通过 osx 上的 parallels 通过 cmd.exe 尝试过此操作）：
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:\Users\timothee\tmp\foo\z2.txt]
cat z2c.txt
abc
rm z2.txt
cat z2c.txt
cat: z2c.txt: No such file or directory
这似乎表明z2c.txt通过创建的mklink /J行为更像是符号链接而不是目录连接（例如：https://cects.com/overview-to-understanding-hard-links-junction-points-and-symbolic-links-in-windows/提到If the target is deleted, its content is still available through the hard link）。
请注意，在资源管理器中，z2c.txt 显示为目录链接，通过资源管理器打开它不起作用（给出：）The directory name is invalid，但它似乎在 cmd.exe 上运行。
这些文档似乎与我观察到的内容相矛盾，而且它似乎mklink /J可以用来规避创建符号链接的限制（必须是管理员或开发人员模式加上 set SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE）。或者它也可能意味着某些程序（cat）对待此类链接的方式与其他程序不同，在这种情况下，我想知道哪些程序理解此类链接。