O que é link simbólico diferente com hard link depois de unlik?

Question

1.

#include <stdio.h>
#include <unistd.h>

void main(){
    link("foo", "bar");
    unlink("foo");
    if(open("bar", 1) < 0)
        printf("open error\n");
    else
        printf("open succeeded\n");
}

2.

#include <stdio.h>
#include <unistd.h>

void main(){
    symlink("foo", "bar");
    unlink("foo");
    if(open("bar", 1) < 0)
        printf("open error\n");
    else
        printf("open succeeded\n");
}

o resultado do primeiro código é "aberto com sucesso".
e o arquivo "foo" é deletado. só permanece "bar", cujo conteúdo é o mesmo com o arquivo "foo".

o reslut frome segundo código é "erro de abertura". e também só permanece "bar".

por que esses resultados são gerados?
1. especialmente, embora cada hardlink e o link simbólico ("bar") aponte o arquivo "foo", o arquivo "foo" foi deletado.
2. porque "bar" não é deletado, após unlink ("foo"). função unlink significa que ele remove o link, que aponta o arquivo especificado (neste caso, "foo")
3. porque o resultado do primeiro código e segundo código é diferente?

    

Answer 1

Vou fazer uma referência rápida a partir de um artigo existente

Com arquivos de hardlink ,

  

Ao excluir arquivos, a parte de dados não é descartada até que todas as partes do nome do arquivo tenham sido excluídas. Há uma contagem no inode que indica quantos nomes de arquivos apontam para esse arquivo, e essa contagem é diminuída em 1 sempre que um desses nomes de arquivos é excluído. Quando a contagem chega a zero, o inode e seus dados associados são excluídos.

Por favor, leia A diferença entre hard links e soft links para detalhes.

Como, você pode estar interessado neste outro factoid em hardlinks,

  

a contagem também reflete quantas vezes o arquivo foi aberto sem ser fechado (em outras palavras, quantas referências ao arquivo ainda estão ativas). Isso tem algumas ramificações que não são óbvias a princípio: você pode excluir um arquivo para que nenhuma parte "filename" aponte para o inode, sem liberar o espaço para a parte de dados do arquivo, porque o arquivo ainda está aberto.

Você poderia tentar isso com seu código de teste.

btw: você pode reavaliar seus dois casos?
Eu acho que você iria obter erro para o caso symlink () e sucesso para o caso link ().
Eu sugiro que você os execute em diretórios diferentes ou use nomes de arquivos diferentes para os dois casos :-)

    

Answer 2

Primeiro de tudo, você tem certeza de que obteve a saída dos programas do jeito certo? Eu tenho uma falha para a versão do symlink e um sucesso para a versão do hard link.

Segundo, passar constantes numéricas como o argumento de sinalizadores para open não é portável e dificulta a leitura do seu código. Os sinalizadores relevantes são definidos em <fcntl.h> e a constante que você está usando é O_WRONLY .

Se você passar um symlink como o primeiro argumento para open , é equivalente a passar o nome para o qual o symlink aponta. No seu exemplo, o link simbólico aponta para um arquivo inexistente, fazendo com que a chamada do sistema falhe. Se você quiser a chamada para criar o arquivo, precisará passar O_WRONLY|O_CREAT como sinalizadores. Isso resultará no arquivo foo sendo criado.

Para o caso do link físico, o nome bar vincula ao conteúdo do arquivo foo em vez do nome. Desvincular foo não altera esse fato, então bar continua a existir e pode ser aberto sem O_CREAT .