Si le fichier est déplacé (dans le même système de fichiers) ou renommé, le descripteur de fichier reste ouvert et peut toujours être utilisé pour lire et écrire le fichier.
Si le fichier est supprimé, le descripteur de fichier reste ouvert et peut toujours être utilisé (ce n'est pas ce à quoi certaines personnes s'attendent). Le fichier ne sera pas vraiment supprimé tant que le dernier handle ne sera pas fermé.
Si le fichier est remplacé par un nouveau fichier, cela dépend exactement comment. Si le contenu du fichier est écrasé, le descripteur de fichier sera toujours valide et accédera au nouveau contenu. Si le fichier existant est dissocié et qu'un nouveau est créé avec le même nom ou si un nouveau fichier est déplacé sur le fichier existant à l'aide de rename() , c'est la même chose que la suppression (voir ci-dessus) - c'est-à-dire que le descripteur de fichier continuera à se référer à l'original version du fichier.
En général, une fois que le fichier est ouvert, le fichier est ouvert, et personne ne peut changer la structure du répertoire - ils peuvent déplacer, renommer le fichier ou mettre autre chose à sa place, il reste simplement ouvert.
Sous Unix, il n'y a pas de suppression, seulement unlink() , ce qui est logique car il ne supprime pas nécessairement le fichier - supprime simplement le lien du répertoire.
Si, d'autre part, le périphérique sous-jacent disparaît (par exemple, une déconnexion USB), le descripteur de fichier ne sera plus valide et est susceptible de donner des IO/erreurs sur toute opération. Encore faut-il le fermer. Cela va être vrai même si l'appareil est rebranché, car il n'est pas judicieux de garder un fichier ouvert dans ce cas.
Les descripteurs de fichiers pointent vers un inode et non vers un chemin, donc la plupart de vos scénarios fonctionnent toujours comme vous le supposez, puisque le descripteur pointe toujours vers le fichier.
Plus précisément, avec le scénario de suppression - la fonction est appelée "unlink" pour une raison, elle détruit un "lien" entre un nom de fichier (un dentry) et un fichier. Lorsque vous ouvrez un fichier, puis que vous le dissociez, le fichier existe toujours jusqu'à ce que son compteur de références atteigne zéro, c'est-à-dire lorsque vous fermez le descripteur.
Modifier : Dans le cas du matériel, vous avez ouvert un handle vers un nœud de périphérique spécifique, si vous débranchez le périphérique, le noyau échouera tous les accès à celui-ci, même si le périphérique revient. Vous devrez fermer l'appareil et le rouvrir.
Je ne suis pas sûr des autres opérations, mais en ce qui concerne la suppression :la suppression n'a tout simplement pas lieu (physiquement, c'est-à-dire dans le système de fichiers) tant que le dernier handle ouvert du fichier n'est pas fermé. Ainsi, il ne devrait pas être possible de supprimer un fichier sous votre application.
Quelques applications (qui ne viennent pas à l'esprit) s'appuient sur ce comportement, en créant, ouvrant et supprimant immédiatement des fichiers, qui vivent ensuite exactement aussi longtemps que l'application - permettant aux autres applications d'être conscientes du cycle de vie de la première application sans avoir besoin de regardez les cartes de processus et autres.
Il est possible que des considérations similaires s'appliquent aux autres éléments.