O que é “ln -L” (--logical) para?

Question

Eu posso ler na página de manual do ln:

   -L, --logical
          make hard links to symbolic link references

Eu li em algum lugar que ln -L poderia ser usado para vincular novamente arquivos que foram excluídos, mas que ainda estão abertos, usando o sistema de arquivos /proc . Por exemplo:

ln -L /proc/1234/fd/12 /tmp/my-file

Mas estou recebendo ENOENT : Nenhum arquivo ou diretório. Se eu tentar em um sistema de arquivos diferente, eu recebo um link inválido para vários dispositivos.

Se eu não posso usar o ln -L para recuperar arquivos apagados, então para que ele poderia ser usado?

    

Answer 1

Os utilitários GNU são documentados principalmente com info páginas. De a página de informações do GNU ln :

‘-L’
‘--logical’
    If -s is not in effect, and the source file is a symbolic link,
    create the hard link to the file referred to by the symbolic link,
    rather than the symbolic link itself. 

Portanto, isso simplesmente desreferencia os links simbólicos fornecidos como argumentos de origem.

    

Answer 2

Bem, uma resposta um pouco mais amigável para os novatos ...

Algumas noções básicas de antemão

Uma visão simples de como os arquivos são armazenados em sistemas UNIX / Linux é: Há uma entrada de diretório que consiste no nome que você vê com ls -l e um número Inode (você pode ver com ls -i ). O Inode contém as informações reais onde seus dados estão armazenados no sistema de arquivos (entre outras coisas como propriedade, permissões, mais Inodes se necessário, e assim por diante):

(Tempo para diversão em UTF-8 ... ;-))

Vista simples:

┌─────────────────┐    ┌───────┐    ┌─────────────┐
│ directory entry │ ─► │ Inode │ ─► │ data blocks │
└─────────────────┘    └───────┘    └─────────────┘

Agora, para a diferença entre o link Difícil e o link simbólico:

Um link físico é simplesmente uma entrada de diretório que aponta para o mesmo Inode como um já existente, enquanto um link simbólico é apenas um arquivo especial que contém o nome de outro arquivo (armazenado diretamente dentro do Inode, se o nome do caminho for pequeno o suficiente para caber dentro). Esta é a razão, porque

• Links físicos para o mesmo arquivo não podem ter permissões de acesso a arquivos diferentes (já que eles estão armazenados no Inode)
• Links físicos devem residir no mesmo sistema de arquivos

Vista simples expandida

 ┌─────────────────┐   
 │    hard link    │ ───────┐
 └─────────────────┘        ▼
 ┌─────────────────┐    ┌───────┐    ┌─────────────┐
 │  example_file   │ ─► │ Inode │ ─► │ data blocks │
 └─────────────────┘    └───────┘    └─────────────┘
          ▲
          └───────────────────────┐
                                  │
 ┌─────────────────┐    ┌─────────┴──────────┐
 │  symbolic link  │ ─► │ filename reference │
 └─────────────────┘    └────────────────────┘

Agora, de volta à opção -L com -s ausente: Permite que você crie um hard link de um arquivo em que um link simbólico aponta para ( Como "link físico" no exemplo acima).

Por que isso poderia ajudar a recuperar arquivos que foram excluídos, mas ainda são usados por um programa aberto?

Bem, o comportamento disso é certamente muito dependente da implementação e sua milhagem pode variar em todas as plataformas UNIX / Linux, mas vou tentar explicar como ele poderia funcionar:

Quando um arquivo é excluído (digamos via rm (1) ), a chamada do sistema chamada é sempre unlink (2) . Ele remove a entrada de diretório e reduz o contador de links (mantido dentro do Inode) em um.

Se o contador de links chegar a zero, é hora de limpar o sistema operacional (na verdade, liberar os blocos de dados para os quais o inode aponta e o próprio Inode. MAS se o arquivo ainda estiver aberto, esta tarefa é normalmente adiada até que o programa usando o inode termine.

Hoje em dia, a maioria dos sistemas UNIX mantêm uma hierarquia de sistema de arquivos /proc , onde é possível procurar referências para abrir arquivos, que são (surpresa!) links simbólicos. Dado que se encontra a entrada correta, ln -L may ajuda a recriar um link para o inode, aumentando o contador de links novamente e evitando que o SO exclua o inode (se o usuário sortudo for rápido o suficiente e o programa ainda está em execução).

Nota: Para que isso funcione, a localização do novo link deve estar no mesmo sistema de arquivos no qual o original foi!

Exemplo Final

 ┌─────────────────┐   
 │   rescue_link   │ ───────┐
 └─────────────────┘        ▼
 ┌─────────────────┐    ┌───────┐    ┌─────────────┐
 │ *** removed *** │    │ Inode │ ─► │ data blocks │
 └─────────────────┘    └───────┘    └─────────────┘
          ▲
          └───────────────────────┐
                                  │
 ┌─────────────────┐    ┌─────────┴──────────┐
 │ /proc/bla/fd/n  │ ─► │ filename reference │
 └─────────────────┘    └────────────────────┘

Palavras finais

Há muitas coisas que podem impedir a criação correta do link e é muito dependente de como o link simbólico é implementado e eu tenho que admitir: tenho sérias dúvidas de que ele funcionará com muitas variantes do UNIX - mas talvez um voluntário que está disposto a gastar algum tempo para testar isso?