Bonjour,
C'est une petite question à laquelle la nécessité d'une réponse n'est pas critique. Cependant, j'aimerais aller au fond des choses pour comprendre ce qui se passe exactement, si quelques-uns parmi vous le savent.
Nous en sommes tous avertis: avant de débrancher sa clef USB de son ordinateur, sous Windows, il faut d'abord l'éjecter. Faute de quoi, jusqu'à son contenu entier peut être perdu.
Pourquoi donc?
Que se passe t-il qui dépasse l'entendement des fonctions open() et close() débutant et terminant les opérations sur fichiers? Car celles-ci sont toujours appelées par les traitements qui procèdent de la même manière pour faire une copie, un déplacement, un ajout ou une suppression de fichier, et qui par principe ne se préoccupent pas de la nature du support physique.
Alors je m'interroge: quel est le fond du problème? La commande close() qui suit la fermeture d'un fichier cible d'une copie, par exemple, ne le ferme pas dans les faits et si l'on retire la clef, même une minute après la copie tout est perdu? Pourquoi cela aurait-il lieu? Absence de flush? Non, ce serait trop curieux.
Ce doit être des opérations spéciales en initialisation de clef USB, lors de sa reconnaissance qui la rendent instable d'une certaine façon, l'endommagent je dirais, et elle ne serait re-stabilisée ("réparée") que lors de l'opération d'éjection.
Ce qui pourrait impliquer - entre autres - qu'aucun open() ne fait d'open, et aucun close() de close, mais que tous les fichiers sont tous ouverts à l'introduction de la clef, et tous fermés lors de l'action système d'éjection.
Qu'est-ce qui explique précisément, à quelque niveau que ce soit (OS, programmation, système, et interne de l'USB), cette contrainte si spécifique de l'éjection?
En vous remerciant,
Grunt.
Partager