Dove vanno gli handle di file aperti quando muoiono?

Cosa succede ai file che vengono eliminati mentre hanno un handle di file aperto a loro?

Mi chiedo questo da quando ho capito che avrei potuto eliminare un file video mentre era in riproduzione in MPlayer e sarebbe stato riprodotto fino alla fine. Da dove sta estraendo i dati? Viene ancora dal disco rigido? È stato copiato nella RAM dopo aver eliminato il file?

Se è ancora sul disco rigido, cosa succede se riempio il file system mentre il programma è in esecuzione leggendo da quello che è essenzialmente spazio non allocato? Se è bufferizzato nella RAM, cosa succede se svuoto i buffer?

Cosa succede se il file si trovava su una condivisione NFS: è archiviato sul server? (Non è un rischio per la sicurezza - DoS da tonnellate di handle di file remoti aperti?)

Fare un lsof -n |grep '(deleted)' volte produce risultati interessanti; se sto aggiornando i pacchetti che sostituiscono i file delle librerie condivise, i programmi che hanno utilizzato quelle librerie saranno comunque in grado di usarli come se nulla fosse cambiato.

Domanda bonus: c'è un modo per recuperare i dati dai morti in questa situazione?

Gli inode persistono ancora sul disco, sebbene non esistano più collegamenti fisici agli inode. Saranno eliminati alla chiusura del descrittore di file. Fino ad allora, il file può essere modificato normalmente, salvo operazioni che richiedono un nome file / collegamento reale.

debugfs e strumenti simili possono essere usati per recuperare il contenuto degli inode.

Il kernel fa riferimento contando su riferimenti all'inode. Vedi la mia risposta a Cosa succede quando chiudo () un descrittore di file? .

L'eliminazione di file aperti non è probabilmente un meccanismo DOS più efficace della semplice apertura di file. I ulimitfile aperti offrono una certa protezione contro questo tentativo di DOS. Si applica a tutti i file aperti, eliminati o meno.

Un file viene cancellato sul filesystem solo quando ogni riferimento ad esso è scomparso. Sia i nomi che gli handle aperti contano come riferimenti. Finché il file è aperto in un programma, non viene eliminato, anche se la maggior parte dei sistemi non consente di ricrearne un nome.

I dati sono ancora sull'unità, ma il file è contrassegnato come con un conteggio dei collegamenti pari a 0. Se il sistema si arresta in modo anomalo, fsck al successivo riavvio sa che deve eliminare i dati. Ciò non porta a una negazione del servizio non più di quanto non faccia un file non cancellato.

Non è possibile ricreare un collegamento al file su un sistema Linux stock per quanto ne so (a meno di bypassare il driver del file system con debugfs o metodi simili), ma è possibile ripristinare facilmente i contenuti: cat /proc/12345/fd/42dove 12345 è l'ID di processo con il file aperto e 42 è il numero del descrittore di file.

Su NFS, quando si elimina un file ancora aperto in alcuni client, il server NFS rinomina il file sul server ma non lo elimina fino a quando tutti i client non hanno rilasciato il file. Nella mia esperienza, il nuovo nome è .nfs…, anche se non so se il nome è lo stesso in tutte le implementazioni NFS.