Considérations relatives à la programmation pour NTFS transactionnel

  • Article

Pour obtenir une description des différentes considérations relatives à la programmation pour ntfs transactionnel, consultez les sections suivantes :

Quels sont les fichiers modifiés qui sont traités

La plupart des modifications de fichiers, telles que les modifications apportées au contenu des fichiers, aux flux, aux points d’analyse, aux attributs et à l’espace de noms du système de fichiers, sont traitées. Quand l’une de ces modifications est effectuée sur un handle de fichier traité, la modification est isolée des autres transactions et la modification est annulée si la transaction est restaurée.

Les modifications qui n’affectent pas le contenu du fichier, les métadonnées ou l’espace de noms du système de fichiers, telles que les modifications apportées à la compression ou à la défragmentation, ne sont pas traitées. Ces modifications ne sont pas isolées des autres transactions et ne sont pas annulées si la transaction est restaurée.

Compression

L’état de compression d’un fichier ouvert dans une transaction ne peut pas être modifié.

Création d’un fichier ou d’un répertoire

Un fichier ou un répertoire créé dans une transaction n’est visible par rien en dehors de la transaction actuelle. En dehors de cette transaction, toute tentative de création d’un fichier portant le même nom échoue avec l’erreur ERROR_TRANSACTIONAL_CONFLICT, en réservant le nom de fichier pour lorsque la transaction est validée ou restaurée.

Suppression d’un fichier

Un fichier ou un répertoire qui est supprimé en appelant la fonction DeleteFileTransacted reste visible par tous les lecteurs externes.

Notes

Tous les handles traités dans le fichier doivent être fermés avant la fin de la transaction. Si les handles ne sont pas correctement fermés, la suppression n’a pas lieu. Tous les descripteurs ouverts du fichier doivent être fermés 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.

Suppression d’un répertoire

Un répertoire supprimé en appelant la fonction RemoveDirectoryTransacted reste visible par tous les lecteurs externes.

Notes

Les mêmes contraintes existent pour les handles ouverts sur les opérations de répertoire traité que pour les fichiers. Pour plus d’informations, consultez Suppression d’un fichier.

Problèmes de verrouillage d’annuaire

Si un fichier est modifié dans une transaction, tous les composants de répertoire du chemin d’accès au fichier sont appelés épinglés contre renommer jusqu’à la fin de la transaction. Autrement dit, le système vous empêche de les renommer jusqu’à ce que la transaction soit validée ou restaurée. Une tentative de renommage d’un répertoire qui est un ancêtre d’un fichier qui a été modifié dans une transaction en cours échoue avec l’erreur ERROR_CANT_BREAK_TRANSACTIONAL_DEPENDENCY.

Énumération d’annuaires

Le contenu d’un répertoire peut être modifié pendant qu’une énumération est en cours à la suite de l’utilisation d’API qui énumèrent, par exemple les fonctions FindFirstFileTransacted et FindNextFile .

Les modifications apportées à un répertoire en dehors d’une transaction ne sont pas isolées de la transaction et sont immédiatement visibles dans la transaction. Par exemple, si un writer non traité ajoute un fichier à un répertoire, le nouveau fichier est immédiatement visible à l’intérieur de la transaction, de sorte que l’appel de la fonction FindFirstFileTransacted ou FindNextFile renvoie le nouveau fichier.

Les modifications apportées à un répertoire à l’intérieur d’une transaction sont isolées jusqu’à ce que la transaction soit validée. Par exemple, un fichier créé dans le répertoire dans le cadre de la transaction. Un lecteur non traité appelant la fonction FindFirstFile ou FindNextFile ne verra pas le fichier nouvellement créé tant que la transaction n’est pas validée.

Fichiers mappés en mémoire

Le client doit appeler la fonction FlushViewOfFile , fermer l’objet de mappage de fichiers et fermer le handle de fichier avant de valider la transaction associée sur un fichier mappé en mémoire.

Flux nommés

Les flux nommés sont entièrement transactionnels, mais le verrouillage est effectué au niveau du fichier, et non au niveau du flux. Les enregistreurs extérieurs à une transaction qui tentent de modifier un flux dans un fichier verrouillé reçoivent l’erreur ERROR_SHARING_VIOLATION.

Vous ne pouvez pas renommer un flux secondaire dans une transaction.

Renommage d’un fichier ou d’un répertoire

Pour renommer un fichier en tant qu’opération transactionnelle, appelez MoveFileTransacted pour déplacer le fichier.

Points d'analyse

Les modifications apportées aux points d’analyse sont traitées, ce qui signifie que si un nouveau point d’analyse est affecté à un fichier dans une transaction, il n’est pas visible pour les autres transactions. De même, les modifications ou la suppression d’un point d’analyse existant ne sont pas visibles tant que la validation n’est pas effectuée.

Codes d’erreur

Le gestionnaire de transactions du noyau (KTM) utilise les codes d’erreur système dans la plage comprise entre 6700 et 6799. Transactional NTFS (TxF) utilise des codes d’erreur Windows dans la plage comprise entre 6800 et 6899. Pour plus d’informations, consultez WinError.h et Codes d’erreur système (6000-8199).

Système de fichiers chiffré

TxF ne prend pas en charge les opérations sur les fichiers EFS. Vous ne pouvez pas ouvrir un fichier chiffré EFS pour les transactions. L’appel de la fonction CreateFileTransacted sur un fichier EFS échoue avec l’erreur ERROR_EFS_NOT_ALLOWED_IN_TRANSACTION. De même, l’appel de la fonction EncryptFile sur un fichier dans une transaction échoue avec l’erreur ERROR_EFS_NOT_ALLOWED_IN_TRANSACTION.

Fonctions d’E/S de fichier et NTFS transactionnelle

TxF fournit de nouvelles fonctions traitées qui prennent un nom de fichier et modifie le comportement des fonctions API d’E/S de fichier existantes qui prennent un descripteur de fichier.

Fonctions traitées

Si vous n’appelez pas l’une des fonctions traitées suivantes à la place de sa version non transactionnée, l’opération ne sera pas traitée :

Par exemple, la fonction CreateFile a maintenant une version transactionnée : CreateFileTransacted.

Fonctions d’E/S de fichier modifiées par TxF

Le tableau suivant répertorie les fonctions dont le comportement est affecté par ntfs transactionnel. Par exemple, le comportement de la fonction ReadFile varie selon que le paramètre hFile a été créé par la fonction CreateFile ou la fonction CreateFileTransacted .

Fonction Description
CloseHandle
 Les applications doivent fermer tous les handles liés à une transaction avant la validation de la transaction. Une application doit fermer un handle traité ouvert avec FILE_FLAG_DELETE_ON_CLOSE avant de valider la transaction pour que l’opération de suppression se produise.
CreateFileMapping
 Si une transaction est associée à hFile, l’objet de mappage de fichiers créé par cette fonction est associé à la même transaction. Les modifications apportées par le biais des vues de cet objet de mappage de fichiers sont traitées. Les applications doivent appeler FlushViewOfFile, annuler le mappage de toutes les vues et fermer tous les handles à l’objet de mappage de fichiers avant de valider les modifications traitées.
FindNextFile
 S’il existe une transaction liée au handle d’énumération de fichiers, les fichiers retournés sont soumis aux règles d’isolation des transactions.
FSCTL_SET_COMPRESSION
 Vous ne pouvez pas modifier l’état de compression d’un fichier ouvert par CreateFileTransacted.
GetFileInformationByHandle et GetFileInformationByHandleEx
 S’il existe une transaction liée au handle de fichier, la fonction retourne des informations pour l’affichage de fichiers isolé.
GetFileSize et GetFileSizeEx
 S’il existe une transaction liée au handle de fichier, la fonction retourne des informations pour l’affichage de fichiers isolé.
GetVolumeInformation
 Si le volume prend en charge les transactions de système de fichiers, la fonction retourne FILE_SUPPORTS_TRANSACTIONS dans lpFileSystemFlags.
MapViewOfFile et MapViewOfFileEx
 Si une transaction est associée au handle de fichier utilisé pour créer l’objet de mappage de fichiers en cours de mappage, la vue associée est traitée. Si la vue est utilisée pour apporter des modifications traitées à un fichier, l’utilisateur doit appeler FlushViewOfFile, fermer l’objet de mappage de fichiers et fermer le handle de fichier avant de valider la transaction associée.
ReadDirectoryChangesW
 S’il existe une transaction liée au handle d’annuaire, les notifications reflètent l’affichage isolé du répertoire. Les modifications apportées aux fichiers en dehors de l’affichage traité du répertoire ne sont pas incluses dans les notifications.
ReadFile, ReadFileEx et ReadFileScatter
 S’il existe une transaction liée au handle de fichier, la fonction retourne des données à partir de la vue traitée du fichier. Un handle de lecture traité est garanti pour afficher la même vue d’un fichier pendant la durée du handle.
SetEndOfFile
 S’il existe une transaction liée au handle, la modification de la position de fin de fichier est traitée.
SetFileInformationByHandle
 S’il existe une transaction liée au handle, les modifications apportées sont traitées pour les classes d’informations FileBasicInfo, FileRenameInfo, FileAllocationInfo, FileEndOfFileInfo et FileDispositionInfo.
SetFileShortName
 S’il existe une transaction liée au handle, la modification du nom court du fichier est traitée.
SetFileTime
 S’il existe une transaction liée au handle, la modification de l’heure du fichier est traitée.
WriteFile, WriteFileEx et WriteFileGather
 S’il existe une transaction liée au handle de fichier, l’écriture de fichier est traitée.