Como o 'lsof' mantém um registro dos nomes de arquivos dos descritores de arquivos abertos?

Question

Eu notei que, se um arquivo for renomeado, lsof exibirá o novo nome.

Para testá-lo, criei um script python :

#!/bin/python
import time

f = open('foo.txt', 'w')
while True:
  time.sleep(1)

Vi que lsof segue a renomeação:

$ python test_lsof.py &
[1] 19698

$ lsof | grep foo | awk '{ print $2,$9 }'
19698 /home/bfernandez/foo.txt

$ mv foo{,1}.txt

$ lsof | grep foo | awk '{ print $2,$9 }'
19698 /home/bfernandez/foo1.txt

Descobriu que isso pode ser feito pelo número inode . Para testar isso, criei um link físico para o arquivo. No entanto, lsof ainda exibe o nome original:

$ ln foo1.txt foo1.link

$ stat -c '%n:%i' foo*
foo1.link:8429704
foo1.txt:8429704

$ lsof | grep foo | awk '{ print $2,$9 }'
19698 /home/bfernandez/foo1.txt

E, se eu excluir o arquivo original, lsof apenas listará o arquivo como excluído, mesmo que ainda exista um link físico:

$ rm foo1.txt
rm: remove regular empty file ‘foo1.txt’? y

$ lsof | grep foo | awk '{ print $2,$9,$10 }'
19698 /home/bfernandez/foo1.txt (deleted)

Então, finalmente ...

Minha pergunta

Qual método o lsof usa para rastrear os descritores de arquivos abertos que permitem:

1. Acompanhe as alterações no nome do arquivo
2. Não está ciente dos links físicos existentes

Answer 1

1. Você está certo em assumir que lsof usa o inode do cache de nomes do kernel. Nas plataformas Linux, o nome do caminho é fornecido pelo sistema de arquivos /proc do Linux.

2. O tratamento de links físicos é melhor explicado no FAQ :

3.3.4 Why doesn't lsof report the "correct" hard linked file path name?

When lsof reports a rightmost path name component for a file with hard links, the component may come from the kernel's name cache. Since the key which connects an open file to the kernel name cache may be the same for each differently named hard link, lsof may report only one name for all open hard-linked files. Sometimes that will be "correct" in the eye of the beholder; sometimes it will not. Remember, the file identification keys significant to the kernel are the device and node numbers, and they're the same for all the hard linked names.

O fato de o nó excluído ser exibido também é específico do Linux (e versões posteriores do Solaris 10, de acordo com o mesmo FAQ ).