Partager via


SetFileValidData, fonction (fileapi.h)

Définit la longueur des données valides du fichier spécifié. Cette fonction est utile dans des scénarios très limités. Pour plus d'informations, consultez la section Notes.

Attention L’utilisation de cette fonction sans considérations de sécurité appropriées peut compromettre la confidentialité et la sécurité des données. Pour plus d'informations, consultez la section Notes.

 

Syntaxe

BOOL SetFileValidData(
  [in] HANDLE   hFile,
  [in] LONGLONG ValidDataLength
);

Paramètres

[in] hFile

Descripteur du fichier. Le fichier doit avoir été ouvert avec le droit d’accès GENERIC_WRITE et le privilège SE_MANAGE_VOLUME_NAME activé. Pour plus d’informations, consultez Sécurité des fichiers et droits d’accès.

Note Le fichier ne peut pas être un fichier réseau, ou être compressé, partiellement alloué ou traité.
 

[in] ValidDataLength

Nouvelle longueur de données valide.

Ce paramètre doit être une valeur positive supérieure à la longueur de données valide actuelle, mais inférieure à la taille de fichier actuelle.

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 0. Pour obtenir des informations détaillées sur l’erreur, appelez GetLastError.

Notes

La fonction SetFileValidData définit la fin logique d’un fichier. Pour définir la taille d’un fichier, utilisez la fonction SetEndOfFile . La taille du fichier physique est également appelée fin du fichier.

Chaque flux de fichiers a les propriétés suivantes :

  • Taille de fichier : taille des données d’un fichier, sur l’octet.
  • Taille d’allocation : taille de l’espace alloué à un fichier sur un disque, qui est toujours un multiple pair de la taille du cluster.
  • Longueur de données valide : longueur des données d’un fichier réellement écrit, sur l’octet. Cette valeur est toujours inférieure ou égale à la taille de fichier.
En règle générale, la fonction SetFileValidData est utilisée par les applications au niveau du système sur leurs propres données privées. Tous les systèmes de fichiers n’utilisent pas une longueur de données valide. Certains systèmes de fichiers peuvent suivre plusieurs plages de données valides. En général, la plupart des applications n’auront jamais besoin d’appeler cette fonction.

La fonction SetFileValidData vous permet d’éviter de remplir des données avec des zéros lors de l’écriture de manière non indispensable dans un fichier. La fonction rend les données du fichier valides sans écrire dans le fichier. Par conséquent, bien que certains gains de performances puissent être réalisés, les données existantes sur disque à partir de fichiers précédemment existants peuvent devenir par inadvertance à la disposition de lecteurs involontaires. Les paragraphes suivants fournissent une description plus détaillée de ce problème potentiel de sécurité et de confidentialité.

Un appelant doit avoir le privilège SE_MANAGE_VOLUME_NAME activé lors de l’ouverture initiale d’un fichier. Les applications doivent appeler SetFileValidData uniquement sur les fichiers qui limitent l’accès aux entités qui ont un accès SE_MANAGE_VOLUME_NAME . L’application doit s’assurer que les plages non écrites du fichier ne sont jamais exposées, sinon des problèmes de sécurité peuvent se produire comme suit.

Si SetFileValidData est utilisé sur un fichier, le gain de performances potentiel est obtenu en ne remplissant pas les clusters alloués pour le fichier avec des zéros. Par conséquent, la lecture à partir du fichier retourne tout ce que contiennent les clusters alloués, potentiellement le contenu d’autres utilisateurs. Il ne s’agit pas nécessairement d’un problème de sécurité à ce stade, car l’appelant doit avoir SE_MANAGE_VOLUME_NAME privilège pour que SetFileValidData réussisse, et toutes les données sur le disque peuvent être lues par ces utilisateurs. Toutefois, cet appelant peut exposer par inadvertance ces données à d’autres utilisateurs qui ne peuvent pas acquérir le privilège SE_MANAGE_VOLUME_PRIVILEGE si les éléments suivants sont :

  • Si le fichier n’a pas été ouvert avec un mode de partage qui refuse d’autres lecteurs, un utilisateur non privilégié peut l’ouvrir et lire les données exposées.
  • Si le système cesse de répondre avant que l’appelant n’ait fini d’écrire la valeur ValidDataLength fournie dans l’appel, lors d’un redémarrage, un utilisateur non privilégié peut ouvrir le fichier et lire le contenu exposé.

Si l’appelant de SetFileValidData a ouvert le fichier avec un contrôle d’accès suffisamment restrictif, les conditions précédentes ne s’appliquent pas. Toutefois, pour les fichiers partiellement écrits étendus avec SetFileValidData (autrement dit, l’écriture n’a pas été effectuée jusqu’à la valeur ValidDataLength fournie dans l’appel), il existe encore une autre vulnérabilité potentielle de confidentialité ou de sécurité. Un administrateur peut copier le fichier vers une cible qui n’est pas correctement contrôlée avec des autorisations ACL restrictives, exposant ainsi par inadvertance les données de la zone étendue à une lecture non autorisée.

C’est pour ces raisons que SetFileValidData n’est pas recommandé pour une utilisation à usage général, en plus des considérations relatives aux performances, comme indiqué ci-dessous.

Pour plus d’informations sur la sécurité et les privilèges d’accès, consultez Exécution avec des privilèges spéciaux et Sécurité des fichiers et droits d’accès.

Vous pouvez utiliser la fonction SetFileValidData pour créer des fichiers volumineux dans des circonstances très spécifiques afin que les performances des E/S de fichiers suivantes puissent être meilleures que d’autres méthodes. Plus précisément, si la partie étendue du fichier est volumineuse et qu’elle est écrite de manière aléatoire, par exemple dans un type de base de données d’application, le temps nécessaire à l’extension et à l’écriture dans le fichier sera plus rapide que l’utilisation de SetEndOfFile et l’écriture de manière aléatoire. Dans la plupart des autres situations, l’utilisation de SetFileValidData n’entraîne généralement aucun gain de performances et peut parfois entraîner une pénalité de performances.

Dans Windows 8 et 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

Configuration requise

   
Client minimal pris en charge Windows XP [applications de bureau uniquement]
Serveur minimal pris en charge Windows Server 2003 [applications de bureau uniquement]
Plateforme cible Windows
En-tête fileapi.h (inclure Windows.h)
Bibliothèque Kernel32.lib
DLL Kernel32.dll

Voir aussi

Fonctions de gestion des fichiers

SetEndOfFile