Como o linux funciona com links simbólicos?

Question

Quero dizer, o que acontece quando algum processo deseja ler um link simbólico? O que está acontecendo quando algo muda um symlink durante um processo de leitura ou até de gravação?

Por exemplo: eu tenho 2 arquivos 100G grandes e similares /mnt/1 e /mnt/2 . /mnt/1 está disponível através do link simbólico /home/user/file . Algum programa A começa a ler /home/user/file . E depois de um tempo, algo muda o link de /mnt/1 para /mnt/2 , mas A ainda está lendo o arquivo.

O programa armazena em cache o caminho absoluto?

Irá falhar e erro, porque o symlink foi alterado ou vai funcionar bem, como se nada tivesse acontecido?

Será que será diferente no caso de /home/user/file estar ligado a um dispositivo de bloco (por exemplo, 2 discos iscsi replicados)?

    

Answer 1

O link simbólico aponta para o nome do arquivo real ( inode ) no sistema de arquivos. Quando o sistema resolve esse symlink para encontrar o arquivo atual e abri-lo, ele encontra e usa o inode do arquivo. Nesse ponto, o caminho que você usou para acessar o arquivo não importa. O que o sistema operacional não armazena em cache, ele lê o arquivo pelo seu inode. Você poderia, pelo que eu entendi, começar a ler o arquivo através de um hard link e remover esse hard link (contanto que o arquivo ainda esteja vinculado de algum outro lugar) , e isso não causaria problemas por tanto tempo como o arquivo foi resolvido (nome string- > inode).

    

Answer 2

Um link simbólico é um pequeno arquivo que contém o local (ou seja, caminho e nome do arquivo) de um arquivo de destino, com um sinalizador na entrada do diretório indicando que é um link simbólico.

Quando você abre um link simbólico, o SO seguirá o local para encontrar o arquivo de destino. Se o alvo é um link simbólico, ele também segue sua localização (1) (2) até que a localização aponte para um arquivo que não seja não um link simbólico (vamos chamá-lo de FinalFile ). Em seguida, o SO obtém o inode do FinalFile (o inode contém metadados como tempo de modificação e também tem um ponteiro para os dados do arquivo). Finalmente, o inode do FinalFile é aberto. De agora em diante, o processo usa esse inode para ler / gravar no arquivo. Como resultado, alterar o nome ou caminho do link simbólico, excluir o link simbólico, alterar o caminho ou o nome do FinalFile ou até mesmo excluir o FinalFile (3) não tem efeito sobre o processo; ainda está lendo do mesmo inode.

Na maioria dos casos, as operações de dados de arquivo no link simbólico afetarão o DestinatioFile (por exemplo, ler e gravar no link simbólico irá ler / escrever no FinalFile ) mas são exceções: a chamada do sistema readlink() lê o conteúdo do próprio link simbólico.

As operações de metadados de arquivo (como renomear ou excluir), por outro lado, geralmente afetam o symlink. Mas há exceções aqui também: a chamada do sistema lstat() é como stat() , exceto que ela retorna informações sobre o link simbólico em vez de no FinalFile (2).

(1) há um limite no número de níveis e as coisas ficam um pouco mais complexas se o local no symlink for um caminho relativo.

(2) Leia o symlink (7): manipulação simbólica de links para mais detalhes.

(3) O comando rm ou a chamada de sistema unlink() não remove fisicamente um arquivo; ele remove a entrada de diretório que aponta para o inode do arquivo. O arquivo em si é removido apenas se ambos a) não houver mais entradas de diretório (links físicos) que se referem ao seu inode e b) nenhum processo tiver o arquivo aberto.