Où vont les descripteurs de fichiers ouverts lorsqu'ils meurent?

Qu'arrive-t-il aux fichiers supprimés alors qu'ils ont un descripteur de fichier ouvert?

Je me le demande depuis que j'ai compris que je pouvais supprimer un fichier vidéo pendant qu'il était en cours de lecture dans MPlayer et qu'il continuerait à jouer jusqu'à la fin. D'où tire-t-il les données? Provient-il toujours du disque dur? At-il été copié dans la RAM une fois que j'ai supprimé le fichier?

S'il se trouve toujours sur le disque dur, que se passe-t-il si je remplis le système de fichiers pendant que le programme exécute la lecture à partir de ce qui est essentiellement de l'espace non alloué? S'il est mis en mémoire tampon dans la RAM, que se passe-t-il si je vide les tampons?

Que se passe-t-il si le fichier se trouve sur un partage NFS - est-il stocké sur le serveur? (N'est-ce pas un risque pour la sécurité - DoS par des tonnes de descripteurs de fichiers distants ouverts?)

Faire un lsof -n |grep '(deleted)'donne parfois des résultats intéressants; si je mets à niveau des packages qui échangent des fichiers de bibliothèque partagée, l'exécution de programmes qui utilisaient ces bibliothèques pourra toujours les utiliser comme si rien n'avait changé.

Question bonus: existe-t-il un moyen de récupérer les données des morts dans cette situation?

Les inodes persistent toujours sur le disque, bien qu'il n'existe plus de liens durs vers les inodes. Ils seront supprimés à la fermeture du descripteur de fichier. Jusque-là, le fichier peut être modifié comme d'habitude, sauf opérations nécessitant un nom de fichier / lien dur.

debugfs et des outils similaires peuvent être utilisés pour récupérer le contenu des inodes.

Le noyau fait référence en comptant sur les références à l'inode. Voir ma réponse à Que se passe-t-il lorsque je ferme () un descripteur de fichier? .

La suppression de fichiers ouverts n'est probablement pas un mécanisme DOS plus efficace que la simple ouverture de fichiers. Les ulimitfichiers ouverts offrent une certaine protection contre cette tentative DOS. Elle s'applique à tous les fichiers ouverts, supprimés ou non.

Un fichier n'est effacé sur le système de fichiers qu'une fois que toute référence à ce dernier a disparu. Les noms et les poignées ouvertes comptent comme des références. Tant que le fichier est ouvert dans un programme, il n'est pas supprimé, bien que la plupart des systèmes ne vous permettent pas de recréer un nom pour celui-ci.

Les données sont toujours sur le lecteur, mais le fichier est marqué comme ayant un nombre de liens de 0. Si le système se bloque, fsck au prochain redémarrage sait qu'il doit supprimer les données. Cela n'entraîne pas plus un déni de service qu'un fichier non supprimé.

Pour autant que je sache, vous ne pouvez pas recréer un lien vers le fichier sur un système Linux d'origine (à moins de contourner le pilote du système de fichiers avec debugfsou des méthodes similaires), mais vous pouvez récupérer le contenu facilement:cat /proc/12345/fd/42 où 12345 est l'ID de processus qui a ouvert le fichier et 42 est le numéro de descripteur de fichier.

Sur NFS, lorsque vous supprimez un fichier qui est toujours ouvert dans certains clients, le serveur NFS renomme le fichier sur le serveur mais ne le supprime pas tant que tous les clients n'ont pas publié le fichier. D'après mon expérience, le nouveau nom est .nfs…, même si je ne sais pas si le nom est le même dans toutes les implémentations NFS.