Perguntas[symlink](unix)

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.

Acabei de construir (a partir do código-fonte) uma versão atual (versão 2.1) no libgpiodmeu RPi 4B. Existem seis (6) "ferramentas de linha de comando" incluídas no tarball de origem do libgpiod. Durante o make installprocesso, essas ferramentas – e suas novas manpáginas – foram instaladas em subpastas em /usr/lib/arm-linux-gnueabihf.

• páginas de manual:./share/man/man1
• ferramentas exe binárias:./bin

Não desinstalei o libgpiodpacote existente do meu sistema. Por enquanto (até eu descobrir se devo ou não manter a versão 2.1, ou se um pacote atualizado for lançado), estou criando links simbólicos apontando /usr/binpara as novas ferramentas no /usr/lib/arm-linux-gnueabihf/bin. Mas não estou claro sobre como lidar com os manproblemas. Quero ver as novas manpáginas; por exemplo, quando eu entro man gpioset, quero ver a página de manual em /usr/lib/arm-linux-gnueabihf/share/man/man1/gpioset.1.

Como o RPi OS é um derivado do Debian, eu esperaria que os manuais fossem instalados na convenção IAW Debian (seja lá o que for). Eu executei um whereisno nome de uma das 6 ferramentas de linha de comando e obtive o seguinte:

$ whereis gpioinfo
gpioinfo: /usr/bin/gpioinfo /usr/bin/gpioinfo.old /usr/share/man/man1/gpioinfo.1.gz

E encontro todos os 6 manuais /usr/share/man/man1(como arquivos compactados "gzip" ). Suponho que uma maneira de substituir as páginas de manual "novas pelas antigas " seria mover ( mv) os manuais antigos e colocar links para os novos em seus lugares. Mas eu esperava algo mais elegante do que isso - talvez uma "linha única" em algum lugar que apontasse para a localização dos novos manuais no formato /usr/lib/arm-linux-gnueabihf/share/man/man1. Existe tal one-liner ?

Existe uma maneira de configurar isso ad hoc - até que o novo libgpiodpacote seja lançado?

Segui este post - Como copiar uma estrutura de pastas e fazer links simbólicos para arquivos?

cp -al /src/dir /dest/dir    # hard-links to leaf-files

cp -as /src/dir /dest/dir    # symlinks to leaf-files

Mas depois de trabalhar uma única vez copiando meu Google Drive montado para um disco local. Parece que parei de funcionar completamente. Qual poderia ser o problema, visto que estou executando exatamente os mesmos comandos

vídeo dele funcionando: https://www.dropbox.com/scl/fi/0mitrqaefzcp7faplhv8z/symlink-server-Screen-Recording-2023-10-11-at-6.37.37-PM.mov?rlkey=kbfxp4plnpps3wfxppty7233y&dl=0

Vídeo dele não funcionando: https://www.dropbox.com/scl/fi/ryowcu9c0cae2uit232gy/symlink-not-working-Screen-Recording-2023-10-11-at-11.32.41-PM.mov?rlkey= n2e9pzpzqfpw28d0tu19dngbs&dl=0

Estou movendo meus arquivos de um computador para outro por meio de um disco rígido externo formatado com NTFS. Tenho uma pasta chamada "biblioteca" com muitos PDFs. Esta pasta contém alguns links simbólicos, pois alguns PDFs (ou seja, livros ou artigos) pertencem a diversas categorias (ou seja, pastas). O problema que estou enfrentando é que não consigo colocar os arquivos em meu novo computador com os links simbólicos intactos (ou seja, sem que eles sejam desreferenciados). Consegui copiar a pasta do computador antigo para o disco rígido externo com os links simbólicos intactos com o comando cp -a. Mas quando uso o mesmo comando para copiar os arquivos do disco rígido para o novo computador, os links simbólicos são desreferenciados (ou seja, substituídos pelo arquivo ao qual se referem). Eu também tenteicp -r --preserve=all, com o mesmo resultado. Então, qual comando preciso usar para obter os links simbólicos do disco rígido externo para o meu novo computador? Perguntado de forma diferente, por que cp -adeixa os links simbólicos intactos ao copiar para o disco rígido externo, mas não na outra direção? Estou no Ubuntu 22.04, caso seja relevante.

EDITAR:

Acabei de notar que, quando conecto o disco rígido ao computador antigo (que está rodando o Ubuntu 16.04), os links simbólicos no disco rígido são exibidos como links e funcionam como tal (ou seja, clicar neles abre o referido arquivo PDF ), enquanto que, quando conecto o disco rígido ao novo computador (que está rodando Ubuntu 22.04), os links simbólicos não são exibidos como links (mas como arquivos PDF) e não funcionam (ou seja, ao clicar neles, o Document Viewer emite a mensagem de erro File type unknown (application/octet-stream) is not supported; ou seja, o Document Viewer tenta abri-los como arquivos PDF em vez de seguir o link). Por que esse comportamento diferente das duas versões do Ubuntu?

Eu tenho um diretório, dir. Dentro do dir, existem links simbólicos e subdiretórios regulares. Eu quero remover dire criar um link simbólico para dirapontar para outro diretório.

Se eu simplesmente fizer isso rm -rf dir, acredito que isso deve remover todos os subdiretórios e links simbólicos dentro dir, mas é seguro fazer isso quando há links simbólicos dentro dir?

Estou tentando criar um link simbólico em /var/lib/pgsql/data/pg_hba.conf(caminho padrão no Fedora) apontando para o arquivo real localizado em outro lugar, por exemplo /var/lib/pgsql/data/pg_hba.conf -> /home/pg_hba.conf(comando para este exemplo: sudo ln -sf /home/pg_hba.conf /var/lib/pgsql/data/pg_hba.conf).

Configurei /home/pg_hba.confas permissões ( -rw-------), proprietário ( postgres) e grupo ( postgres) para serem exatamente como o /var/lib/pgsql/data/pg_hba.confarquivo original, até tentei chmod 777. Quando eu mudo para o usuário postgrese eu cat /var/lib/pgsql/data/pg_hba.conf(que agora é um link simbólico), ele imprime com sucesso o conteúdo do /home/pg_hba.confarquivo.

No entanto, quando tento aplicar as alterações, sudo systemctl restart postgresqlrecebo o seguinte erro

A tarefa para postgresql.service falhou porque o processo de controle foi encerrado com código de erro.

Consulte "systemctl status postgresql.service" e "journalctl -xeu postgresql.service" para obter detalhes.

Eu verifiquei os logs, mas não há nenhuma outra informação útil.

Só está funcionando quando aponto meu link simbólico para um arquivo no mesmo diretório ( /var/lib/pgsql/data/) que é totalmente inútil (ex: /var/lib/pgsql/data/pg_hba.conf -> /var/lib/pgsql/data/pg_hba.conf.bak)

Se eu apontar para qualquer outro lugar, não funcionará, mesmo que /var/lib/pgsqlseja o diretório inicial do postgresusuário!

Eu sou novo no Linux, então tentei criar um link simbólico com meu ~/.bashrcarquivo apenas para tentar (ex:) ~./bashrc -> /home/.bashrcEu escrevi um echo "TEST!"dentro deste arquivo e apliquei a nova configuração com . ~/.bashrce funciona muito bem, meu TEST!foi impresso com sucesso .

Então, qual é o problema com o PostgreSQL? Como posso corrigir esse erro e manter um link simbólico no pg_hba.confarquivo?

Obrigado por suas respostas

Escrevi um script de link simbólico para alguém de outra equipe executar em um diretório ao qual não tenho acesso e parecia ter causado algo inesperado.

destination_path=/path/to/dest/
source_path=/path/to/src

for dir in first second
do
    # replace existing symlink
    for subdir in {1000..1020}
    do 
        ln -sf $source_path/$dir/$subdir $destination_path/$dir/$subdir
    done
done

Antes de o script ser executado, path/to/dest/$direle contém links simbólicos 1000, 1001, ..., 1020vinculados a um conjunto diferente de diretórios. Meu script destina-se a substituir esses links simbólicos por links simbólicos para /path/to/src/$dir/$subdir, mas, em vez de fazer isso, parece ter criado os links simbólicos dentro do link simbólico existente.

Por exemplo, /path/to/dest/$dir/1000costumava ser um link simbólico e, depois de executar meu script /path/to/dest/$dir/1000, ainda aponta para o mesmo lugar, mas dentro de /path/to/dest/$dir/1000, há um link simbólico 1000que aponta para $source_path/$dir/$subdir/1000.

Isso não deveria ter ocorrido com meu script certo? Tentei reproduzir isso localmente com uma estrutura de diretório de destino simulada e não consegui reproduzir esse problema.

Editar: após uma pesquisa mais aprofundada, parece que eu deveria ter usado ln -sfnem vez de apenas ln -sf? Qual é a maneira mais fácil de remediar isso?

Alguém me disse isso: "Eu sei que os links simbólicos não são usados ​​no Linux ao carregar uma biblioteca".

No entanto, isso não me parece correto. Muitas vezes, tive que consertar links simbólicos quebrados quando estava mexendo no Linux.

Posso encontrar informações sobre links simbólicos, como eles funcionam e como são criados.

Posso encontrar informações sobre bibliotecas compartilhadas e estáticas e como elas funcionam.

Mas não consigo encontrar nenhuma documentação que descreva o processo de carregamento da biblioteca de como os links simbólicos são usados ​​ao carregar bibliotecas. Especialmente quando há várias versões da biblioteca.

Alguém pode me indicar uma documentação que descreva como os links simbólicos são usados ​​para carregar bibliotecas no Linux?

Atualizar

Depois de alguma pesquisa, acredito que a pessoa estava insinuando que os .solinks simbólicos não são usados ​​ao carregar uma biblioteca.

Estou tentando instalar um aplicativo necessário para minha universidade. Sempre que tento criar um link simbólico para o arquivo .desktop da pasta original, ele o compacta de alguma forma e o coloca no arquivo .local/share/applications, onde desejo colocar o .desktop. Como sei que está compactado? Está vermelho no terminal.

Aqui está uma foto com ele na pasta de origem:

Aqui está uma foto com ele na pasta de destino (.local/share/applications):

O problema é que não consigo abrir o aplicativo no menu do sistema operacional. O arquivo não aparece no menu.

Acontece com muita frequência se eu quiser criar um link simbólico: estou recebendo o erro Too many symbolic links. O que isso significa e por que só consigo resolver esse erro quando estou no diretório onde desejo criar o link simbólico?

Por exemplo:

cd /foo/bar
/foo/bar: sudo ln -s /some/dir /foo/bar

Isso funciona.

Isso me dá o erro:

cd ~
~: sudo ln -s /some/dir /foo/bar