Por que um link simbólico do Windows é diferente daquele no Unix?

Question

Estou pesquisando na Web sobre isso. Tudo o que posso encontrar afirma que o Windows mklink se comporta como Unix ln -s ( exemplo neste site ).

No entanto, quero configurar o JDK para que eu possa acessá-lo apenas como javac e java de qualquer lugar. Eu escolhi adicionar apenas esses dois em uma pasta separada à variável de ambiente Path em vez da pasta bin inteira porque há muitas outras coisas lá (não relacionadas: isso importa?).

Eu fiz isso com sucesso no passado em uma caixa do Debian através de ln -s , então aparentemente deve funcionar muito bem com mklink , mas o que acontece é que eu recebo um erro "não pode encontrar DLL" como se eu tinha simplesmente feito uma cópia dos executáveis.

Então, a pergunta é: por que esses dois comandos se comportam de maneira diferente? (embora eles não digam)

    

Answer 1

O mais provável é que o executável seja iniciado a partir do link simbólico com seu atual diretório aquele em que o link simbólico reside, em vez daquele em que o executável reside, portanto, as DLLs no diretório do executável não são encontradas.

Concordo que, de acordo com a definição do algoritmo de pesquisa, dada por Microsoft, as DLLs deveriam ter sido encontradas. Esta é provavelmente uma deficiência no algoritmo de procura de DLL do Windows e não há nada que você possa fazer sobre isso.

Uma solução alternativa seria usar outro mecanismo que o symlink, armazenar na pasta Path um arquivo .bat em vez de um symlink. O arquivo seria algo como:

cd \path\to\exe-folder
exe-file