FlushViewOfFile, fonction (memoryapi.h)

Article
02/28/2024

Écrit sur le disque une plage d’octets dans une vue mappée d’un fichier.

Syntaxe

BOOL FlushViewOfFile(
  [in] LPCVOID lpBaseAddress,
  [in] SIZE_T  dwNumberOfBytesToFlush
);

Paramètres

[in] lpBaseAddress

Pointeur vers l’adresse de base de la plage d’octets à vider sur la représentation disque du fichier mappé.

[in] dwNumberOfBytesToFlush

Nombre d’octets à vider. Si dwNumberOfBytesToFlush est égal à zéro, le fichier est vidé de l’adresse de base jusqu’à la fin du mappage.

Valeur retournée

Si la fonction réussit, la valeur de retour est différente de zéro.

Si la fonction échoue, la valeur de retour est égale à zéro. Pour obtenir des informations détaillées sur l’erreur, appelez GetLastError.

Remarques

Le vidage d’une plage d’une vue mappée lance l’écriture de sale pages de cette plage sur le disque. Les pages incorrectes sont celles dont le contenu a changé depuis que la vue de fichier a été mappée. La fonction FlushViewOfFile ne vide pas les métadonnées du fichier et n’attend pas de retourner les modifications jusqu’à ce que les modifications soient vidées du cache du disque matériel sous-jacent et physiquement écrites sur le disque. Pour vider toutes les pages sale ainsi que les métadonnées du fichier et vous assurer qu’elles sont physiquement écrites sur le disque, appelez FlushViewOfFile, puis appelez la fonction FlushFileBuffers.

Lors du vidage d’un fichier mappé en mémoire sur un réseau, FlushViewOfFile garantit que les données ont été écrites à partir de l’ordinateur local, mais pas que les données résident sur l’ordinateur distant. Le serveur peut mettre en cache les données du côté distant. Par conséquent, FlushViewOfFile peut retourner avant que les données n’ont été physiquement écrites sur le disque.

Lors de la modification d’un fichier via une vue mappée, l’horodatage de la dernière modification peut ne pas être mis à jour automatiquement. Si nécessaire, l’appelant doit utiliser SetFileTime pour définir l’horodatage.

Dans Windows Server 2012, cette fonction est prise en charge par les technologies suivantes.

Technologie	Prise en charge
Protocole Server Message Block (SMB) 3.0	Oui
Basculement transparent SMB 3.0 (TFO)	Oui
SMB 3.0 avec partages de fichiers avec montée en puissance parallèle (SO)	Oui
Système de fichiers du volume partagé de cluster (CsvFS)	Oui
Système de fichiers résilient (ReFS)	Oui

Lorsque CsvFs est suspendu, cet appel peut échouer avec une erreur indiquant qu’il existe un conflit de verrou.

Exemples

Pour obtenir un exemple, consultez Lecture et écriture à partir d’un affichage fichier.

Configuration requise

Condition requise	Valeur
Client minimal pris en charge	Windows XP [applications de bureau \| applications UWP]
Serveur minimal pris en charge	Windows Server 2003 [applications de bureau \| applications UWP]
Plateforme cible	Windows
En-tête	memoryapi.h (inclure Windows.h, Memoryapi.h)
Bibliothèque	onecore.lib
DLL	Kernel32.dll