Os sistemas de arquivos Linux podem resolver um caminho relativo antes de resolver um link simbólico?

Sou novo usuário de Linux aqui, recém-transferido do Windows 10 para o Fedora 41. Tenho muita experiência com muitos sistemas operacionais, incluindo vários sistemas de arquivos *nix e semelhantes ao Unix.

Tenho uma prática padrão de usar links simbólicos de pastas de teste para repositórios de código para recriar a estrutura de pasta de produção implantada localmente para teste, mantendo o teste e o repositório de código claramente separados. Tenho muitos projetos configurados assim para teste local.

Isto se parece com o seguinte, por exemplo:

~/dev
  test
    a-project
      app => ../../code/a-project/src
        (cfg)
        (web)
      dta
        cfg
  code
    a-project
      src
        cfg
        web

A chave para esse problema é que a src/cfgpasta (que na produção é a app/cfgpasta) contém arquivos que têm referências relativas a arquivos opcionais nos dta/cfgquais são carregados se eles existirem na produção, esperados para serem relativos à app/cfgpasta. Assim, ../../dta/cfg/Optional.jsonquando implantado, faz referência à dtapasta. O PWD é a raiz do aplicativo (em testes, isso é ~/dev/test/a-projecte todos os caminhos no software são especificados em relação ao PWD. Esses caminhos são manipulados em código Java, usando Filea classe Java, então este não é um problema de comportamento do shell.

Isso funciona perfeitamente no Windows, já que o sistema de arquivos considera o caminho app/cfg/../../dta/cfg/Optional.jsonexatamente como ele parece e resolve as referências relativas primeiro, resultando em dta/cfg/Optional.json(o inicial app/cfgsendo eliminado pelo seguinte ../...

Mas o Linux aparentemente resolve o link simbólico primeiro ( app/cfg/=> dev/code/project/src/)e só então aplica os segmentos de caminho relativos ../../dta/cfg/Optional.json, resultando em um arquivo não encontrado porque, é claro, o arquivo não está localizado em ~/dev/code/project/dta/cfg.

Independentemente de argumentos sobre se isso é tecnicamente correto ou não, há alguma maneira de eu dizer ao Linux em qualquer nível para resolver segmentos de caminho relativos antes de resolver links simbólicos para que esse comportamento inesperado e imprevisível não ocorra? Além de ser confuso e contraintuitivo para mim, tenho muito código existente que espera que os caminhos resolvam referências relativas primeiro, ou seja, usando o caminho aparente, não o caminho subjacente.

O sistema de arquivos para meu trabalho de desenvolvimento é ext4 com case folding habilitado (vindo do Windows e precisando permanecer compatível com outros desenvolvedores usando Mac e Windows), e eu realmente, realmente gostaria de evitar fazer uma mudança desestabilizadora e invasiva em várias classes Java para implementar a resolução de caminho relativo antes de passar o caminho para o sistema operacional; tanto porque é potencialmente frágil, levando a falhas de segurança, quanto porque é necessário apenas para meus testes, já que sistemas de produção (servidores Ubuntu Linux) não precisam desses links simbólicos.