Cosa c'è dietro un collegamento simbolico?

Question

Come sono gestiti i collegamenti simbolici internamente dai sistemi UNIX/Linux. È noto che un collegamento simbolico può esistere anche senza un vero file di destinazione (collegamento Dangling). Quindi cos'è ciò che rappresenta internamente un collegamento simbolico.

In Windows, la risposta è reparse point.

Domande:

Se la soluzione di un inode in UNIX/Linux?

Se sì, il numero di inode sarà lo stesso per target e collegamenti?

In caso affermativo, l'inode del collegamento può avere autorizzazioni diverse da quelle dell'ode di destinazione (se ne esiste uno)?

Answer 1

Non si tratta di UNIX/Linux ma dell'implementazione del filesystem - ma sì, Unix/Linux usa gli inode a livello di kernel e le implementazioni del filesystem hanno inode (almeno quelli virtuali).

In generale, i link simbolici sono semplicemente file (btw, le directory sono file anche), che sono:

• bandiera file-type nel "inode" che dice al sistema di questo file è un "link simbolico"
• contenuto di file: percorso verso la destinazione - in altre parole: un collegamento simbolico è semplicemente un file che contiene un nome file con una bandiera nell'inode.

I file system virtuali possono avere anche collegamenti simbolici, quindi controllare FUSE o altre sorgenti di implementazione del file system. (Ext2/ext3/ufs..etc)

Quindi,

Se la soluzione un inode in UNIX/Linux?

dipende dall'implementazione del file system, ma sì, generalmente l'inode contiene un "tipo di file" (e proprietari, diritti di accesso, data e ora, dimensioni, puntatori ai blocchi di dati). Ci sono filesystem che non hanno inode s (in una implmementation fisica) ma hanno solo "inode virtuali" per mantenere la compatibilità con il kernel.

Se sì, il numero di inode sarà lo stesso per target e collegamenti?

No. Di solito, il collegamento simbolico è un file con il proprio inode, (con il tipo di file, propri blocchi di dati, ecc)

Se sì, può nell'inode link può disporre di autorizzazioni diverse da quella di inode del bersaglio (se uno esiste)?

Questo è circa come vengono gestiti i file di collegamento simbolico. Di solito il kernel non consente modifiche alle autorizzazioni di link simbolici e i collegamenti simbolici hanno sempre le autorizzazioni predefinite.Potresti scrivere il tuo filesystem che consentirebbe diversi permessi per i link simbolici, ma ti metteresti nei guai, perché programmi comuni come chmod non modificano le autorizzazioni sui symlink stessi, quindi rendere inutile un tale file system comunque)

A capire la differenza tra hardlink e link simbolici, dovresti prima capire le directory.

Le directory sono file (con differenziazione di un flag nell'inode) che indicano al kernel, "gestisce questo file come una mappa di file-name a inode_number". Gli hard-link sono semplicemente nomi di file che si associano allo stesso inode. Quindi, se la directory-file contiene:

file_a: 1000 
file_b: 1001 
file_c: 1000 

i mezzi di cui sopra, in questa directory sono 3 file:

• file_a descritti da inode 1000
• file_b descritto da inode 1001 e
• file_c ancora descritto dall'inode 1000 (quindi è un hard link con file_a, non hardlink a file_a - perché è impossibile dire quale nome di file è venuto prima - il sono identici).

Questa è la differenza principale per i collegamenti simbolici, in cui l'inode di file_b (inode 1001) potrebbe avere contenuti "file_a" e una bandiera che significa "questo è un collegamento simbolico". In questo caso, file_b sarebbe un collegamento simbolico che punta a file_a.

Answer 2

Si può anche facilmente esplorare da soli:

$ touch a 
$ ln -s a b 
$ ln a c 
$ ls -li 
total 0 
95905 -rw-r--r-- 1 regnarg regnarg 0 Jun 19 19:01 a 
96990 lrwxrwxrwx 1 regnarg regnarg 1 Jun 19 19:01 b -> a 
95905 -rw-r--r-- 2 regnarg regnarg 0 Jun 19 19:01 c 

L'opzione -i a ls mostra numeri di inode nella prima colonna. Puoi vedere che il link simbolico ha un numero di inode diverso mentre il collegamento fisico ha lo stesso. È inoltre possibile utilizzare il comando stat(1):

$ stat a 
    File: 'a' 
    Size: 0   Blocks: 0   IO Block: 4096 regular empty file 
Device: 28h/40d Inode: 95905  Links: 2 
[...] 

$ stat b 
    File: 'b' -> 'a' 
    Size: 1   Blocks: 0   IO Block: 4096 symbolic link 
Device: 28h/40d Inode: 96990  Links: 1 
[...] 

Se si vuole fare questo a livello di codice, è possibile utilizzare la chiamata di sistema lstat(2) per trovare informazioni relative al link simbolico in sé (il suo numero di inode, ecc), mentre stat(2) riportate le informazioni relative il target del link simbolico, se esiste. Esempio in Python:

>>> import os 
>>> os.stat("b").st_ino 
95905 
>>> os.lstat("b").st_ino 
96990