I collegamenti fisici vengono conteggiati come file normali?

Mi chiedevo se ci fosse un modo per registrarlo, ma dal momento che la maggior parte dei moderni motori di ricerca non funzionano bene con frasi lunghe più di 5 parole, ho bisogno di aiuto su questo.

Mi chiedevo questo perché sto realizzando uno script bash che deve registrare i file come determinati tipi e prendere le decisioni di conseguenza. Tecnicamente questo non è importante per il mio progetto, ma ero curioso.

Inoltre, se sono considerati file regolari, allora c'è un modo per verificare se questi file sono hard link senza dover analizzare ls -i? E c'è un modo per verificare se qualche file arbitrario, X, è collegato a qualche altro file arbitrario, Y, senza usare il find -icomando?

Nei sistemi in stile Unix, la struttura dei dati che rappresenta gli oggetti del filesystem (in altre parole, i dati su un file), è memorizzata in quello che viene chiamato un "inode".

Il nome di un file è solo un collegamento a questo inode e viene definito "collegamento reale". Non vi è alcuna differenza tra il nome assegnato a un file e qualsiasi collegamento successivo. Quindi la risposta è "sì": un hard link è un file normale e, in effetti, un file normale è un hard link.

Il lscomando ti mostrerà quanti hard link ci sono al file.

Per esempio:

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

Qui abbiamo creato un file chiamato /tmp/hello.txt. L' 1output da ls -lindica che esiste 1 link reale a questo file. Questo hard link è il nome file stesso /tmp/hello.txt.

Se ora creiamo un altro collegamento reale a questo file:

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

ora puoi vedere che entrambi i nomi dei file indicano che ci sono 2 hard link al file. Nessuno di questi è il nome file "corretto", sono entrambi ugualmente validi. Possiamo vedere che entrambi puntano allo stesso inode (in questo caso, 5374043):

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

C'è un malinteso comune sul fatto che questo sia diverso per le directory. Ho sentito gente dire che il numero di collegamenti restituiti da lsuna directory è il numero di sottodirectory, incluso .e ..che non è corretto . O almeno, mentre ti darà il numero corretto, è giusto per le ragioni sbagliate!

Se creiamo una directory e facciamo una ls -ldotteniamo:

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

Questo mostra che ci sono 2 hard link a questa directory. Questi sono:

/tmp/testdir
/tmp/testdir/.

Nota che non/tmp/testdir/.. è un collegamento a questa directory, è un collegamento a . E questo ti dice perché il "numero di sottodirectory" funziona. Quando creiamo una nuova sottodirectory:/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

ora puoi vedere che ci sono 3 hard link alla /tmp/testdirdirectory. Questi sono:

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

Quindi ogni nuova sottodirectory aumenterà il conteggio dei collegamenti di uno, a causa della ..voce che contiene.

I collegamenti fisici vengono conteggiati come file normali?

I collegamenti fissi contano come qualsiasi cosa siano collegati. Puoi collegarti a qualsiasi cosa sullo stesso filesystem.

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  

Ogni collegamento fisico a qualsiasi cosa è equivalente, l'oggetto sottostante rimane attivo fintanto che esiste un collegamento (modifica: non simbolico) (anche un descrittore di file aperto, per il quale ho imbarazzante causa di gratitudine).

Il sistema imporrà le regole sui collegamenti alle directory, otterrai un collegamento con nome a una directory e il sistema aggiungerà automaticamente il suo .collegamento incorporato e tutti i collegamenti delle sottodirectory ..(nota che .in ls ha due collegamenti) ma questo è un controllo esplicito, su alcuni modded gli utenti con privilegi di sistema che promettono che promettono di non creare loop possono aggiungere essi stessi nuovi collegamenti. Al filesystem non importa, può rappresentare bene i grafici di directory arbitrari, ma nessuno vuole gestirli.

Esistono (un sacco di file system non unix) che non funzionano in questo modo, inclusi alcuni che chiamano ciò che offrono come "collegamenti fisici" sostitutivi. OS X ha raccolto un equivalente su HFS + (che non li ha nativamente) se ricordo bene, non so quanto fedelmente conservi la semantica qui.