énumération CF_OPEN_FILE_FLAGS (cfapi.h)

Article
02/23/2024

Indicateurs pour demander diverses autorisations lors de l’ouverture d’un fichier.

Syntax

typedef enum CF_OPEN_FILE_FLAGS {
  CF_OPEN_FILE_FLAG_NONE = 0x00000000,
  CF_OPEN_FILE_FLAG_EXCLUSIVE = 0x00000001,
  CF_OPEN_FILE_FLAG_WRITE_ACCESS = 0x00000002,
  CF_OPEN_FILE_FLAG_DELETE_ACCESS = 0x00000004,
  CF_OPEN_FILE_FLAG_FOREGROUND = 0x00000008
} ;

Constantes


`CF_OPEN_FILE_FLAG_NONE` Valeur : 0x00000000 Aucun indicateur de fichier ouvert.
`CF_OPEN_FILE_FLAG_EXCLUSIVE` Valeur : 0x00000001 Lorsqu’il est spécifié, CfOpenFileWithOplock retourne un handle de partage et demande une rh (OPLOCK_LEVEL_CACHE_READ \| OPLOCK_LEVEL_CACHE_HANDLE) oplock sur le fichier. Appel CreateFile normal qui s’ouvre pour l’un des FILE_EXECUTE \| FILE_READ_DATA \| FILE_WRITE_DATA \| FILE_APPEND_DATA \| DELETE (ou les deux GENERIC_READ \| GENERIC_WRITE) interrompt le blocage en raison du conflit de partage, comme décrit dans la section Remarques . Le propriétaire de l’oplock peut terminer et confirmer.
`CF_OPEN_FILE_FLAG_WRITE_ACCESS` Valeur : 0x00000002 Lorsqu’il est spécifié, CfOpenFileWithOplock tente d’ouvrir le fichier ou le répertoire avec FILE_READ_DATA/FILE_LIST_DIRECTORY et un accès FILE_WRITE_DATA/FILE_ADD_FILE ; sinon, il tente d’ouvrir le fichier ou le répertoire avec FILE_READ_DATA/FILE_LIST_DIRECTORY.
`CF_OPEN_FILE_FLAG_DELETE_ACCESS` Valeur : 0x00000004 Lorsqu’il est spécifié, CfOpenFileWithOplock tente d’ouvrir le fichier ou le répertoire avec un accès DELETE ; sinon, le fichier s’ouvre normalement.
`CF_OPEN_FILE_FLAG_FOREGROUND` Valeur : 0x00000008 Lorsque cet indicateur est utilisé, CfOpenFileWithOplock ne demande pas d’oplock. Cela doit être utilisé lorsque l’appelant agit comme une application de premier plan. c’est-à-dire qu’ils ne se soucient pas de savoir si le handle de fichier créé par cette API provoque des violations de partage pour d’autres appelants, et ils ne se soucient pas de briser les blocages d’opération qui peuvent déjà se trouver sur le fichier. Ainsi, ils ouvrent le handle sans demander un oplock. Note: Le comportement en arrière-plan par défaut demande un oplock lors de l’ouverture du handle de fichier afin que leur appel échoue s’il existe déjà un oplock, et qu’ils puissent être amenés à fermer leur handle s’ils doivent s’écarter du chemin pour éviter de provoquer une violation de partage ultérieurement. Sauf si l’appelant spécifie CF_OPEN_FILE_FLAG_EXCLUSIVE à CfOpenFileWithOplock, l’oplock qu’il obtient sera uniquement OPLOCK_LEVEL_CACHE_READ, et non (OPLOCK_LEVEL_CACHE_READ \| OPLOCK_LEVEL_CACHE_HANDLE), il n’y aura donc pas la protection contre les violations de partage qu’une application en arrière-plan peut normalement souhaiter.

Remarques

Une application en arrière-plan souhaite généralement fonctionner de manière transparente sur les fichiers. En particulier, ils veulent éviter de provoquer des violations de partage avec d’autres ouvreurs (au premier plan). Pour ce faire, ils prennent un (OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE) oplock, tel que serait accordé à l’aide de CF_OPEN_FILE_FLAG_EXCLUSIVE avec CfOpenFileWithOplock. Ensuite, si un autre ouvreur dont les modes de partage/d’accès demandés entrent en conflit avec le mode de l’application en arrière-plan, le blocage d’opération de l’application en arrière-plan s’interrompt. Cela invite l’application en arrière-plan à fermer son handle de fichier (pour un handle Cf, qui le rend non valide , le handle sous-jacent réel a été fermé). Une fois que l’application en arrière-plan ferme son handle, l’autre demande d’ouvrir le produit sans rencontrer la violation de partage. Tout cela fonctionne en raison de la partie OPLOCK_LEVEL_CACHE_HANDLE de l’oplock. Sans CF_OPEN_FILE_FLAG_EXCLUSIVE, l’oplock n’a qu’une protection OPLOCK_LEVEL_CACHE_READ, de sorte que la protection contre les violations de partage n’est pas fournie.

Lorsque CF_OPEN_FILE_FLAG_EXCLUSIVE n’est pas spécifié, l’ouverture est tout partager et obtient un OPLOCK_LEVEL_CACHE_READ oplock.

Un appel CreateFile normal n’interrompt pas le blocage d’opération. Si le CreateFile normal spécifie un mode de partage qui entre en conflit avec l’accès du handle Cf (pour instance, si le CreateFile normal ne spécifie pas FILE_SHARE_READ), le CreateFile normal échoue avec ERROR_SHARING_VIOLATION. L’oplock ne s’interrompt pas tant que l’autre appelant n’émet pas d’E/S en conflit, comme une écriture. Lorsque cela se produit , l’arrêt d’opération est un avertissement uniquement.

Configuration requise

Condition requise	Valeur
Client minimal pris en charge	Windows 10, version 1709 [applications de bureau uniquement]
Serveur minimal pris en charge	Windows Server 2016 (applications de bureau uniquement)
En-tête	cfapi.h

Voir aussi

CfOpenFileWithOplock

CreateFile

Partager via