Os links físicos contam como arquivos normais?

Question

Eu queria saber se havia uma maneira de registrar isso, mas como a maioria dos mecanismos de pesquisa modernos não funciona bem com frases de mais de cinco palavras, preciso de ajuda para isso.

Eu queria saber isso porque estou fazendo um script bash que tem que registrar arquivos como certos tipos e tomar decisões em conformidade. Isso tecnicamente não é importante para o meu projeto, mas fiquei curioso.

Além disso, se forem considerados arquivos regulares, existe uma maneira de verificar se esses arquivos estão vinculados sem ter que analisar ls -i ? E existe uma maneira de verificar se algum arquivo arbitrário, o X, está ligado a algum outro arquivo arbitrário, Y, sem usar o comando find -i ?

    

Answer 1

Em sistemas no estilo Unix, a estrutura de dados que representa objetos do sistema de arquivos (em outras palavras, os dados sobre um arquivo), é armazenada no que é chamado de "inode".

Um nome de arquivo é apenas um link para esse inode e é chamado de "link físico". Não há diferença entre o primeiro nome que um arquivo é dado e qualquer link subseqüente. Portanto, a resposta é "sim": um link físico é um arquivo normal e, na verdade, um arquivo comum é um link físico.

O comando ls mostrará quantos links físicos existem para o arquivo.

Por exemplo:

seumasmac@comp:~$ echo Hello > /tmp/hello.txt
seumasmac@comp:~$ ls -l /tmp/hello.txt 
-rw-rw-r-- 1 seumasmac seumasmac 6 Oct  4 13:05 /tmp/hello.txt

Aqui, criamos um arquivo chamado /tmp/hello.txt . O 1 na saída de ls -l indica que há um link físico para esse arquivo. Esse link físico é o próprio nome do arquivo /tmp/hello.txt .

Se criarmos agora outro link físico para este arquivo:

seumasmac@comp:~$ ln /tmp/hello.txt /tmp/helloagain.txt
seumasmac@comp:~$ ls -l /tmp/hello*
-rw-rw-r-- 2 seumasmac seumasmac 6 Oct  4 13:05 /tmp/helloagain.txt
-rw-rw-r-- 2 seumasmac seumasmac 6 Oct  4 13:05 /tmp/hello.txt

agora você pode ver que os dois nomes de arquivos indicam que há dois links para o arquivo. Nenhum destes é o nome do arquivo "correto", ambos são igualmente válidos. Podemos ver que ambos apontam para o mesmo inode (neste caso, 5374043):

seumasmac@comp:~$ ls -i /tmp/hello*
5374043 /tmp/helloagain.txt  5374043 /tmp/hello.txt

Há um equívoco comum de que isso é diferente para diretórios. Ouvi pessoas dizerem que o número de links retornados por ls para um diretório é o número de subdiretórios, incluindo . e .. , o que é incorreto . Ou, pelo menos, enquanto isso lhe dará o número correto, é certo pelas razões erradas!

Se criarmos um diretório e fizermos um ls -ld , obteremos:

seumasmac@comp:~$ mkdir /tmp/testdir
seumasmac@comp:~$ ls -ld /tmp/testdir
drwxrwxr-x 2 seumasmac seumasmac 4096 Oct  4 13:20 /tmp/testdir

Isso mostra que há dois links para esse diretório. Estes são:

/tmp/testdir
/tmp/testdir/.

Note que /tmp/testdir/.. não é um link para este diretório, é um link para /tmp . E isso lhe diz por que a coisa "número de subdiretórios" funciona. Quando criamos um novo subdiretório:

seumasmac@comp:~$ mkdir /tmp/testdir/dir2
seumasmac@comp:~$ ls -ld /tmp/testdir
drwxrwxr-x 3 seumasmac seumasmac 4096 Oct  4 13:24 /tmp/testdir

agora você pode ver que há três links para o diretório /tmp/testdir . Estes são:

/tmp/testdir
/tmp/testdir/.
/tmp/testdir/dir2/..

Assim, cada novo subdiretório aumentará a contagem de links em um, devido à entrada .. que ele contém.

    

Answer 2

Do hard links count as normal files?

Links físicos contam como o que estão vinculados. Você pode vincular a qualquer coisa no mesmo sistema de arquivos.

mkdir test
cd !$

>file
ln -s file sym
mknod pipe p

ln file file2
ln -P sym sym2
ln pipe pipe2

ls -al

# sockets, too:
cat >tsock.c <<\EOD
#include <sys/socket.h>
#include <sys/un.h>
int main(int n, char **a)
{
        struct sockaddr_un test = { AF_UNIX, "socket" };
        int testfd = socket(AF_UNIX, SOCK_SEQPACKET, 0);
        bind(testfd,(struct sockaddr *)&test,sizeof test);
}
EOD
make tsock
./tsock

ln socket socket2

ls -al

# even devices if you want:
sudo mknod mytty c 5 0
ln mytty mytty2
sudo chmod 666 mytty

ls -al
# notice permissions are on an object not on the links to it:
echo Hi, Kilroy! >mytty2  

Cada hardlink para qualquer coisa é equivalente, o objeto subjacente permanece enquanto houver qualquer link (edit: non-symbolic) para ele (mesmo um descritor de arquivo aberto, pelo qual eu tenho uma causa embaraçosa para ser muito grato) .

O sistema aplicará regras em links de diretórios, você receberá um link nomeado para um diretório e o sistema adicionará automaticamente seu link . incorporado e todos os subdiretórios ' .. links (observe que . nos ls acima tem dois links), mas essa é uma verificação explícita, em alguns sistemas modificados, os usuários privilegiados que prometem promessa de promessa de não fazer loops podem adicionar novos links. O sistema de arquivos não se importa, ele pode representar gráficos de diretório arbitrários, mas ninguém quer lidar com eles.

Existem (muitos sistemas de arquivos não-unix) que não funcionam dessa forma, incluindo alguns que chamam o que eles oferecem de "hard links" substitutos. O OS X possui um equivalente no HFS + (que não tem nativamente) se bem me lembro, não sei com que fidelidade preserva a semântica aqui.