Partager via

Utilisation de NTFS transactionnel

  • Article

Handles de fichiers traités

Transactional NTFS (TxF) lie un handle de fichier à une transaction. Pour les opérations qui fonctionnent sur un handle (par exemple, les fonctions ReadFile et WriteFile ), l’appel de fonction API réel ne change pas. Pour les opérations de fichier qui prennent un nom, il existe des fonctions traitées explicites pour ces opérations. Par exemple, au lieu d’appeler CreateFile, appelez CreateFileTransacted. Cela crée un handle de fichier traité, qui peut ensuite être utilisé pour toutes les opérations de fichier nécessitant un handle. Toutes les opérations suivantes utilisant ce handle sont des opérations traitées.

Utilisation de base de TxF

La série d’étapes suivante représente l’utilisation la plus basique pour TxF. Des scénarios plus complexes sont également pris en charge, à la discrétion du concepteur d’application.

  1. Créez une transaction en appelant la fonction KTM CreateTransaction ou en utilisant l’interface IKernelTransaction du Coordinateur de transactions distribuées (DTC).
  2. Obtenez le ou les handles de fichiers traités en appelant CreateFileTransacted.
  3. Modifiez le ou les fichiers si nécessaire à l’aide des handles de fichier traités.
  4. Fermez tous les handles de fichiers traités associés à la transaction créée à l’étape 1.
  5. Commitez ou annulez la transaction en appelant la fonction KTM ou DTC correspondante.

Points clés du modèle de programmation TxF

Le modèle de programmation TxF présente les points clés suivants à prendre en compte lorsque vous développez une application TxF :

  • Il est vivement recommandé qu’une application ferme tous les handles de fichiers traités avant de valider ou de restaurer une transaction. Le système invalide tous les handles traités lorsqu’une transaction se termine. Toute opération, à l’exception de la fermeture, effectuée sur un handle traité après la fin de la transaction retourne l’erreur suivante : ERROR_HANDLE_NO_LONGER_VALID.
  • Un fichier est vu comme une unité de stockage. Les mises à jour partielles et les remplacements de fichiers complets sont pris en charge. Plusieurs transactions ne peuvent pas modifier simultanément le même fichier.
  • Les E/S mappées en mémoire sont transparentes et cohérentes avec les E/S de fichier standard. Une application doit vider et fermer une section ouverte avant de valider une transaction. L’échec de cette opération peut entraîner des modifications partielles du fichier mappé dans la transaction. Une restauration échoue si cette opération n’est pas effectuée.

Erreurs de programmation courantes

Les erreurs courantes suivantes peuvent se produire lors du développement d’applications traitées :

  • Utilisation d’un handle de fichier une fois la transaction terminée.
  • Échec de la fermeture des handles aux fichiers et répertoires supprimés avant de valider une transaction, ce qui empêche les opérations de suppression de se produire. Cet événement doit se produire avant d’effectuer la validation pour que l’opération de suppression soit considérée comme faisant partie de la transaction. Cela est dû au fait que le système ne supprime pas réellement un fichier tant que le dernier handle de celui-ci n’est pas fermé, même lorsque l’opération n’est pas traitée, dans le cadre du sous-système d’E/S de fichier Windows.
  • Échec de prise en compte des restaurations de transaction initiées par le système, ce qui peut se produire à tout moment ; par exemple, une transaction est annulée si les ressources système sont épuisées.