FlushViewOfFile, fonction (memoryapi.h)
É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 |
Voir aussi
Création d’un affichage de fichiers