FSCTL_REQUEST_OPLOCK IOCTL (winioctl.h)
Demande un verrou opportuniste (oplock) sur un fichier et accuse réception du fait qu’un relâchement du verrou opportuniste s’est produit.
Pour effectuer cette opération, appelez la fonction DeviceIoControl à l’aide des paramètres suivants.
BOOL DeviceIoControl(
(HANDLE) hDevice, // handle to file
FSCTL_REQUEST_OPLOCK, // dwIoControlCode
(LPVOID) lpInBuffer, // input buffer
(DWORD) nInBufferSize, // size of input buffer
(LPVOID) lpOutBuffer, // output buffer
(DWORD) nOutBufferSize, // size of output buffer
(LPDWORD) lpBytesReturned, // number of bytes returned
(LPOVERLAPPED) lpOverlapped // OVERLAPPED structure
);
Remarques
Cette opération est utilisée uniquement par les applications clientes qui demandent un verrou opportuniste (oplock) à partir d’un serveur local. Les applications clientes qui demandent des verrous opportunistes à partir de serveurs distants ne doivent pas les demander directement. Le redirecteur réseau demande en toute transparence des verrous opportunistes pour l’application. Une tentative d’utilisation de cette opération pour demander des verrous opportunistes à des serveurs distants entraîne le refus de la demande.
Le code de contrôle FSCTL_REQUEST_OPLOCK offre des fonctionnalités plus efficaces que les codes de contrôle associés suivants : FSCTL_REQUEST_OPLOCK_LEVEL_1, FSCTL_REQUEST_OPLOCK_LEVEL_2, FSCTL_REQUEST_FILTER_OPLOCK et FSCTL_REQUEST_BATCH_OPLOCK. La demande de différents niveaux d’oplock peut être effectuée à plusieurs reprises sur le même handle sans fermer et rouvrir le handle lors de l’utilisation de FSCTL_REQUEST_OPLOCK ; les autres codes de contrôle nécessitent que le handle soit fermé, puis rouvert avec CreateFile pour apporter une telle modification. Pour ce faire, manipulez le membre RequestedOplockLevel de la structure REQUEST_OPLOCK_INPUT_BUFFER lors de la réécriture du code de contrôle FSCTL_REQUEST_OPLOCK .
Le tableau suivant récapitule comment la capacité de mise en cache des types oplock disponibles à partir de FSCTL_REQUEST_OPLOCK correspond aux oplocks de niveau 2, de niveau 1 et de lot.
| Code de contrôle alternatif | Valeur équivalente des indicateurs RequestedOplockLevel | Type Oplock |
|---|---|---|
| FSCTL_REQUEST_BATCH_OPLOCK | OPLOCK_LEVEL_CACHE_READ \| OPLOCK_LEVEL_CACHE_WRITE \| OPLOCK_LEVEL_CACHE_HANDLE |
RWH |
| FSCTL_REQUEST_OPLOCK_LEVEL_1 | OPLOCK_LEVEL_CACHE_READ \| OPLOCK_LEVEL_CACHE_WRITE |
L/E |
| FSCTL_REQUEST_OPLOCK_LEVEL_2 | OPLOCK_LEVEL_CACHE_READ |
R |
L’utilisation du code de contrôle FSCTL_REQUEST_OPLOCK avec le membre RequestedOplockLevel défini pour OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE accorder un oplock de type RH. Un oplock RH est similaire au oplock de filtre accordé par le code de contrôle FSCTL_REQUEST_FILTER_OPLOCK . Toutefois, notez que le filtre oplock n’autorise qu’un seul client à contenir un oplock sur un fichier à la fois ; FSCTL_REQUEST_OPLOCK permet à plusieurs clients à la fois d’avoir le verrou RH sur un fichier. Une autre différence est que FSCTL_REQUEST_FILTER_OPLOCK nécessite un accusé de réception d’arrêt d’opération avant que les écritures puissent se produire, où FSCTL_REQUEST_OPLOCK ne le fait pas parce que la notification d’arrêt d’opération est à titre consultatif uniquement et que les écritures sont autorisées à aller de l’avant sans accusé de réception. Pour plus d’informations, consultez Cassant les oplocks.
Un code de contrôle FSCTL_REQUEST_OPLOCK échoue si le fichier est ouvert en mode non chevauchement (synchrone).
Pour connaître les implications des E/S qui se chevauchent sur cette opération, consultez la section Remarques de la rubrique DeviceIoControl .
Dans Windows 8 et Windows Server 2012, ce code est pris en charge par les technologies suivantes.
| Technologie | Prise en charge |
|---|---|
| Protocole Server Message Block (SMB) 3.0 | No |
| Basculement transparent SMB 3.0 (TFO) | No |
| SMB 3.0 avec partages de fichiers avec montée en puissance parallèle (SO) | No |
| Système de fichiers du volume partagé de cluster (CsvFS) | Oui |
| Système de fichiers résilient (ReFS) | Oui |
En outre, à partir de Windows 8 et Windows Server 2012, le code de contrôle FSCTL_REQUEST_OPLOCK peut être utilisé pour demander un oplock sur un répertoire ainsi qu’un fichier. Une requête oplock sur un répertoire peut spécifier OPLOCK_LEVEL_CACHE_READ ou OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE dans le membre RequestedOplockLevel.
Un oplock R ou RH sur un répertoire passe à Aucun lorsque le contenu d’une énumération du répertoire change. Par exemple, l’ajout/la suppression d’un fichier dans le répertoire, la modification de la taille d’un fichier dans le répertoire, la modification de l’horodatage d’un fichier dans le répertoire, etc., briserait tous le blocage d’oplock sur le répertoire. Cette interruption d’opération ne nécessite pas d’accusé de réception avant que les modifications apportées au répertoire ne se produisent ; il s’agit d’un avis uniquement.
Un oplock RH sur un répertoire passe à R lorsque le répertoire lui-même est renommé ou supprimé. Cette interruption d’opération nécessite un accusé de réception avant que la modification du répertoire puisse se produire.
Configuration requise
| Client minimal pris en charge | Windows 7 [applications de bureau uniquement] |
| Serveur minimal pris en charge | Windows Server 2008 R2 [applications de bureau uniquement] |
| En-tête | winioctl.h (inclure Windows.h) |