Il existe une fonction à définir la valeur "longueur de données valides": SetFileValidData, mais je n'ai pas trouvé un moyen de obtenir la valeur "longueur de données valide".Comment obtenir une "longueur de données valide" d'un fichier?
Je veux savoir sur le fichier donné si l'EOF est différent du VDL, car l'écriture après le VDL dans le cas de VDL<EOF entraînera une pénalité de performance comme décrit here.
J'ai trouvé la page this, affirme que:
il n'y a pas de mécanisme pour interroger la valeur de la VDL
La réponse est "vous ne pouvez pas". Si vous tenez compte des performances, vous pouvez définir le VDL sur EOF, mais notez que vous pouvez autoriser l'accès à la mémoire obsolète sur votre disque - la partie entre ces deux pointeurs, qui est supposée être des zéros si vous voulez accéder à ce fichier sans régler le VDL pour pointer l'EOF.
Je pense que vous êtes confus quant à ce que "longueur de données valides" effectivement signifie. Vérifiez this answer. Fondamentalement, tandis que SetEndOfFile vous permet d'augmenter la longueur d'un fichier rapidement, et alloue l'espace disque, si vous passez à la (nouvelle) fin de fichier pour y écrire, tout l'espace disque alloué en plus devra être écrasé par des zéros, ce qui est plutôt lent.
SetFileValidData permet de ignorer cette remise à zéro. Vous dites au système: «Je suis d'accord avec tout ce qui se trouve dans ces blocs de disque, continuez avec ça». (Ceci est la raison pour laquelle vous avez besoin du SE_MANAGE_VOLUME_NAME privilege, car il pourrait révéler des données priviledged aux utilisateurs non privilégiés si vous ne remplacez pas les données. Les utilisateurs avec ce privilege peuvent accéder aux données d'entraînement brutes de toute façon.)
Dans les deux cas , vous avez défini la nouvelle taille effective du fichier. (Que vous pouvez lire en retour.) Que, exactement, devrait un séparé "lisez le fichier de données valides" rapport? SetFileValidDatadit le système que ce qui est dans ces blocs de disque est « valide » ...
approche différente de l'explication:
Le documentation mentionne que la « longueur de données valides » est étant suivi; le but est que le système sache quelle plage (de la fin de validité des données à la fin du fichier) il doit encore mettre à zéro, dans le contexte de SetEndOfFile, si nécessaire (par ex. fichier). Vous ne pas besoin de relire cette valeur, car la seule façon qu'il pourrait être différent du fichier réel taille est parce que vous, vous-même, a changé via les fonctions ci-dessus ...
Je suis bien conscient de la signification de la VDL. Dans mon scénario, il est parfaitement logique de l'interroger, car je veux * rejeter * les fichiers qui me sont fournis avec VDL 0 et EOF grande. (Rappelez-vous que VDL n'est pas toujours défini par moi + il a peut-être changé depuis le dernier set à l'aide de SetFileValidData, en raison de l'écriture près de la fin du fichier. – avim
@avim: Mettre cette information dans la question elle-même aurait été un long chemin pour ne pas la fermer parce qu'elle n'était pas claire et obtenir des réponses précises. Cela étant dit, je ne pense pas qu'il existe un moyen de lire cette propriété, à moins de s'appuyer sur un comportement non documenté. Je ne suis toujours pas sûr de votre cas d'utilisation; la documentation disponible sur VDL n'est pas claire sur la sémantique dans un cas comme celui que vous décrivez, donc vous pourriez déjà en supposer trop. – DevSolar
merci @DevSolar, il semble qu'il n'y a aucun moyen de le lire – avim
Le SetValidData (selon MSDN) peut être utilisé pour créer par exemple un fichier volumineux sans avoir à écrire dans le fichier. Pour une base de données, cela va allouer une zone de stockage (contiguë). En conséquence, il semble que la taille du fichier sur le disque aura changé sans qu'aucune donnée n'ait été écrite dans le fichier.
Par conséquent, tout GetValidData (qui n'existe pas) renvoie simplement la taille du fichier, vous pouvez donc utiliser GetFileSize qui renvoie la taille de fichier "valide".
En outre, la "longueur de données valide" typique est la même que la taille réelle du fichier. –
@JoachimPileborg Je ne traite pas du cas typique ... – avim
Curieux, n'allez-vous pas simplement inclure les octets qui existent sur le disque après la fin des données de fichier? – Marichyasana