Os links físicos contam como arquivos normais?

Fiquei me perguntando se havia uma maneira de registrar isso, mas como a maioria dos mecanismos de pesquisa modernos não funciona bem com frases com mais de 5 palavras, preciso de ajuda.

Fiquei me perguntando isso, porque eu estou fazendo um script bash que tem que registrar arquivos como certos tipos e tomar decisões em conformidade. Tecnicamente, isso não é importante para o meu projeto, mas fiquei curioso.

Além disso, se eles são considerados arquivos regulares, existe uma maneira de verificar se esses arquivos estão vinculados sem necessidade de analisar ls -i? E existe uma maneira de verificar se algum arquivo arbitrário, X, está vinculado com algum outro arquivo arbitrário, Y, sem usar o find -icomando?

Nos sistemas estilo Unix, a estrutura de dados que representa os 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 este inode e é chamado de "link físico". Não há diferença entre o primeiro nome dado a um arquivo e qualquer link subsequente. Portanto, a resposta é "sim": um link físico é um arquivo regular e, de fato, um arquivo comum é um link físico.

O lscomando 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 nós criamos um arquivo chamado /tmp/hello.txt. O 1resultado da saída ls -lindica que há 1 link físico para este arquivo. Esse link físico é o próprio nome do arquivo /tmp/hello.txt.

Se agora criarmos 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 existem 2 links físicos para o arquivo. Nenhum desses é o nome de arquivo "adequado", 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

Existe um equívoco comum de que isso seja diferente para diretórios. Ouvi pessoas dizerem que o número de links retornados por lsum diretório é o número de subdiretórios, incluindo .e o ..que está incorreto . Ou, pelo menos, apesar de fornecer o número correto, é correto pelos motivos errados!

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 existem 2 links físicos para este diretório. Esses são:

/tmp/testdir
/tmp/testdir/.

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

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 existem 3 links físicos para o /tmp/testdirdiretório. Esses são:

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

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

Os links físicos contam como arquivos normais?

Os links físicos contam como o que eles 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  

Todo link direto para qualquer coisa é equivalente, o objeto subjacente permanece desde que haja qualquer link (editar: não simbólico) para ele (até mesmo um descritor de arquivo aberto, pelo qual tenho motivo embaraçoso de ser muito grato).

O sistema aplicará regras nos links de diretório, você obterá um link nomeado para um diretório e o sistema adicionará automaticamente o .link incorporado e os links de qualquer subdiretório ..(observe que .no ls acima há dois links), mas isso é uma verificação explícita, em alguns modded usuários privilegiados de sistemas que prometem prometer prometer não criar loops podem adicionar novos links. O sistema de arquivos não se importa, pode representar gráficos de diretório arbitrários muito bem, mas ninguém quer lidar com eles.

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