![为什么 Windows 符号链接与 Unix 中的符号链接不同?](https://linux22.com/image/1537307/%E4%B8%BA%E4%BB%80%E4%B9%88%20Windows%20%E7%AC%A6%E5%8F%B7%E9%93%BE%E6%8E%A5%E4%B8%8E%20Unix%20%E4%B8%AD%E7%9A%84%E7%AC%A6%E5%8F%B7%E9%93%BE%E6%8E%A5%E4%B8%8D%E5%90%8C%EF%BC%9F.png)
我一直在网上搜索这个问题。我找到的所有资料都表明 Windows 的mklink
行为与 Unix 类似ln -s
(此站点中的示例)。
但是,我想设置 JDK,以便我可以从任何地方访问它javac
。java
我选择将这两个文件放在单独的文件夹中,而不是整个bin
文件夹添加到 Path 环境变量中,因为里面还有很多其他内容(无关紧要:这有关系吗?)。
我以前曾通过 在 Debian 机器上成功完成此操作ln -s
,因此显然它应该可以很好地工作mklink
,但相反,我收到了“找不到 DLL”错误,就好像我只是复制了可执行文件一样。
所以,问题是:为什么这两个命令的行为不同?(尽管他们说不要这么做)
答案1
最有可能的是,可执行文件是从符号链接启动的,其当前目录是符号链接所在的目录,而不是可执行文件所在的目录,因此找不到可执行文件目录中的 DLL。
我同意,根据 Microsoft 给出的搜索算法定义,应该可以找到 DLL。这很可能是 Windows 的 DLL 搜索算法存在缺陷,对此您无能为力。
一种解决方法是使用除符号链接之外的另一种机制,在 Path 文件夹中存储一个.bat
文件而不是符号链接。该文件看起来类似于:
cd \path\to\exe-folder
exe-file