scopri quali descrittori di file condividono la stessa "descrizione file aperta"

Se lo faccio (in una shell tipo Bourne):

exec 3> file 4>&3 5> file 6>> file

I descrittori di file 3 e 4, poiché 4 è stato modificato dup()da 3, condividono la stessa descrizione del file aperto (stesse proprietà, stesso offset all'interno del file ...). Mentre i descrittori di file 5 e 6 di quel processo si trovano su una diversa descrizione del file aperto (ad esempio, ognuno ha il proprio puntatore nel file).

Ora, in lsofuscita, tutto ciò che vediamo è:

zsh     21519 stephane    3w   REG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    4w   REG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    5w   REG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    6w   REG  254,2        0 10505865 /home/stephane/file

È un po 'meglio con lsof +fg:

zsh     21519 stephane    3w   REG          W,LG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    4w   REG          W,LG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    5w   REG          W,LG  254,2        0 10505865 /home/stephane/file
zsh     21519 stephane    6w   REG       W,AP,LG  254,2        0 10505865 /home/stephane/file

(qui su Linux 3.16) in quanto vediamo fd 6 ha flag diversi, quindi deve essere una descrizione del file aperto diversa da quella su fd 3, 4 o 5, ma da ciò non possiamo dire che fd 5 è su un diversa descrizione del file aperto . Con -o, potremmo anche vedere l'offset, ma di nuovo lo stesso offset non garantisce che sia la stessa descrizione del file aperto .

C'è un non-intrusivo ¹ modo per scoprirlo? Esternamente o per i descrittori di file propri di un processo?

_{¹ . Un approccio euristico potrebbe essere quello di cambiare i flag di un fd fcntl()e vedere quali altri descrittori di file hanno i loro flag aggiornati di conseguenza, ma questo ovviamente non è l'ideale né infallibile}

Per Linux 3.5 e versioni successive, questo può essere realizzato con kcmp (3) :

KCMP_FILE

• Controlla se un descrittore di file idx1 nel processo pid1 fa riferimento alla stessa descrizione del file aperto (vedi open (2) ) del descrittore di file idx2 nel processo pid2 . L'esistenza di due descrittori di file che fanno riferimento alla stessa descrizione di file aperto può verificarsi a seguito di dup (2) (e simili) fork (2) o del passaggio di descrittori di file tramite un socket di dominio (vedere unix (7) ).

La pagina man fornisce un esempio specifico per il caso d'uso OP richiesto. Nota che questo syscall richiede che il kernel sia compilato con CONFIG_CHECKPOINT_RESTOREset.

Quello che stai cercando di confrontare sono i struct filepuntatori a cui fanno riferimento i descrittori di file. (All'interno del kernel c'è una task_structstruttura di dati per ogni thread. Contiene un puntatore a un'altra struttura chiamata il files_struct. E quella struttura contiene un array di puntatori, ognuno a un struct file. È quello struct fileche contiene l'offset di ricerca, i flag aperti e un pochi altri campi.)

Non conosco alcun modo visibile all'utente per vedere i puntatori files_structnell'uso diverso da alcuni strumenti invadenti. Ad esempio, SystemTap potrebbe ricevere un PID e potrebbe trovare il corrispondente task_structe seguire i puntatori. Se stai cercando passivo, però, penso che sia a questo proposito. Dell ha rilasciato molto tempo fa uno strumento chiamato KME (Kernel Memory Editor) che forniva un'interfaccia simile a un foglio di calcolo per vivere la memoria del kernel e poteva fare quello che volevi, ma non è mai stato portato su 64-bit. (Ho provato e non l'ho mai fatto funzionare completamente, e non ero sicuro del perché.)

Uno dei motivi per cui non stai trovando lsofutile è che non vede neanche quei puntatori (ma guarda l' +fopzione per i sistemi non Linux). Potresti teoricamente confrontare tutti i campi in struct filee pensare che le due strutture siano uguali, ma potrebbero comunque provenire da open(2)chiamate separate .

Dai un'occhiata allo script SystemTap di pfiles per idee. Se lo modificassi per stampare l'indirizzo del struct file, avresti la tua soluzione. Potresti anche controllare open_file_by_pid.stp poiché c'è una funzione in essa che percorre files_struct, ad esempio. la tabella dei descrittori di file, guardando gli struct fileoggetti ...

Potrei chiederti cosa stai cercando di realizzare?

Ecco una soluzione specifica per Linux: / proc / self / fd è una directory di collegamenti simbolici per handle di file aperti nel processo corrente. Puoi semplicemente confrontare i valori dei link. Diventa più complicato quando si usa un processo figlio, perché il bambino avrà un / proc / sé diverso perché è un collegamento simbolico dipendente dal pid. Puoi risolvere questo problema usando / proc / $$ / fd dove $$ è il pid desiderato.