Travailler avec des fichiers. - page 5

Nouveau commentaire
 
Yedelkin:

Question 1 : Pensez-vous qu'il y a une erreur de frappe dans la documentation, et qu'au lieu de "Date de dernière lecture", il faudrait dire quelque chose comme "Date de dernière ouverture" ?

Oui, voici le verbatim :

lpLastAccessTime [out, optionnel]

Un pointeur vers une structureFILETIME pour recevoir la date et l'heure du dernier accès au fichier ou au répertoire. La dernière heure d'accès inclut la dernière fois que le fichier ou le répertoire a été écrit, lu ou, dans le cas de fichiers exécutables, exécuté.

Traduction libre : le dernier accès comprend la dernière fois que le fichier a été lu ou écrit ou exécuté (s'il est exécutable).

Je me trompe probablement au sujet de l'annulation de la poignée, mais il y a aussi ce texte intéressant :

Tous les systèmes de fichiers ne peuvent pas enregistrer les heures de création et de dernier accès et tous les systèmes de fichiers ne les enregistrent pas de la même manière. Par exemple, sur FAT, le temps de création a une résolution de 10 millisecondes, le temps d'écriture a une résolution de 2 secondes et le temps d'accès a une résolution d'un jour (en réalité, la date d'accès). Par conséquent, la fonctionGetFileTime peut ne pas renvoyer les mêmes informations sur l'heure du fichier définies à l'aide de la fonction SetFileTime.

NTFS retarde les mises à jour de la dernière heure d'accès à un fichier jusqu'à une heure après le dernier accès. NTFS permet également de désactiver la mise à jour de la dernière heure d'accès. Le dernier temps d'accès n'est pas mis à jour sur les volumes NTFS par défaut.

Dans la situation actuelle, le bonheur est attendu lorsque les propriétés du fichier sont récupérées sans "réouverture" du handle.

Apparemment, pas de chance, du moins pas en ce qui concerne les secondes.
 
TheXpert:

Oui, voici le verbatim :

Traduction libre : le dernier accès comprend la dernière fois que le fichier a été lu ou écrit ou exécuté (s'il est exécutable).

Je me trompe probablement au sujet de l'annulation de la poignée, mais il y a aussi ce texte intéressant :

Apparemment, il n'y a pas de chance, du moins pas en ce qui concerne les secondes.

Merci pour l'élargissement de l'esprit ! Ouais... C'est dommage.

Ce script indique qu'au lieu de l'identifiant "Last read date", FILE_ACCESS_DATE renvoie l'heure de la dernière fermeture du fichier:

int handle_file;
void OnStart()
  {
   Print("===============================================");
   handle_file=FileOpen("Ye_file2.bin",FILE_READ|FILE_WRITE|FILE_BIN);
   switch(handle_file)
     {
      case  INVALID_HANDLE: break;
      default:
         Print("Дата создания файла Ye_file2.bin: ",(datetime)FileGetInteger(handle_file,FILE_CREATE_DATE));
         for(int i=0;i<3;i++)
           {
            Sleep(2000);
            FileReadInteger(handle_file,CHAR_VALUE);
            Print("Дата последнего чтения Ye_file2.bin: ",(datetime)FileGetInteger(handle_file,FILE_ACCESS_DATE));
           }
         Sleep(3000);
         Print("Время обращения к FileClose(handle_file): ",TimeTradeServer());
         FileClose(handle_file);
     }
  }
 
TheXpert:

Mais malgré les conclusions sauvages, les tests sont révélateurs, nous attendons donc les commentaires des développeurs sur le fonctionnement de la fonction lorsqu'il n'y a pas de changement.

D'ailleurs, au cours des trois derniers mois, je n'ai reçu aucun commentaire. J'évite donc d'utiliserFileFlush() pour l'instant.
 

Il me semble que FileFlush ne devrait pas ralentir/accélérer le programme s'il est utilisé à la place de FileClose.

Cela n'a pas de sens de l'utiliser en boucle pour chaque enregistrement. Imaginez la lenteur de Word s'il réenregistrait chaque fois qu'un document était modifié (surtout si ce document contient beaucoup de texte et d'images). FileFLush facilite uniquement l'enregistrement sans fermer les fichiers.

Les développeurs ont dû vouloir dire que (par exemple) :

OnInit - FileOpen

On Tick - FileWrite FileFlush

(et ici les données sont sauvegardées -FileFlash- dans la boucle, pas à chaque passage de la boucle, mais après que la boucle soit terminée)

OnDeinit FileClose.

L'intérêt de FileFlash est d'écrire dans ce fichier tout le temps que l'Expert Advisor est en cours d'exécution, afin de ne pas réinitialiser constamment le gestionnaire de fichier et le tampon de fichier mystique.

......niverse)

 
Yedelkin:
À propos, je n'ai reçu aucun commentaire au cours des trois derniers mois, c'est pourquoi j'ai évité d'utiliser FileFlush() pour l'instant.
De toute façon, il ne garantit pas une sauvegarde immédiate. Il est donc logique de l'utiliser pour sauvegarder l'état actuel sans fermer la poignée.
 
Yedelkin:
À propos, je n'ai reçu aucun commentaire au cours des trois derniers mois, c'est pourquoi j'ai évité d'utiliser FileFlush() pour l'instant.

Pour mieux comprendre le sens de l'utilisation de la fonction FileFlush(), nous devons réfléchir au concept de tampon d'entrée/sortie de fichier... Comme vous le savez, les informations du disque sont stockées en octets et écrire chaque octet individuellement (au fur et à mesure qu'ils arrivent) est le comble du gaspillage ! Si l'on considère ce processus du point de vue "matériel", à chaque demande d'opération d'écriture d'octet, le système d'exploitation devrait "remuer la tête de l'auteur" du disque dur ! Et un disque dur est cinématique ! En d'autres termes, c'est le plus lent de tous les appareils informatiques. Alors quelle est la solution ? Une solution très simple ! Dans la mémoire de l'ordinateur est créé un tampon de données (généralement quelques dizaines de kilo-octets) dans lequel les données de la fonction FileWrite et similaires sont envoyées. Dès que ce tampon sera complètement rempli, le système l'écrit complètement sur un disque dur comme le bloc continu de données, ainsi la manipulation inutile de la tête du lecteur n'est pas effectuée, et les données sont simplement écrites dans UNE MACHINE ! Maintenant, calculez combien de fois la vitesse d'écriture de 32 kilo-octets d'informations à la fois augmente par rapport à l'écriture de chaque octet séparément de la même taille ;) Et le calcul est assez simple... Pour chaque opération d'écriture, la tête du lecteur est d'abord positionnée, puis l'opération d'écriture est effectuée. Et c'est sans compter tout le travail difficile d'une opération de lecture/écriture :) Dans le cas d'un tampon, nous positionnons la tête une fois et écrivons le bloc entier en un seul flux !

Cela dit, tant que votre tampon n'est pas plein, vos données n'apparaissent pas physiquement dans le fichier ( !!!), ou tant que vous ne fermez pas le fichier lui-même, auquel cas le tampon (ou plutôt ce qu'il en reste) est immédiatement écrit sur le disque. C'est là que la fonction FileFlush entre en jeu. Lorsque vous avez "écrit" une information dans le fichier et que vous avez besoin qu'elle apparaisse dans le fichier (par exemple, cette information peut déjà être utilisée par un autre programme, un indicateur, un Expert Advisor...), vous pouvez alors appeler la fonction FileFlush, qui videra physiquement le contenu du tampon sur le disque (dans un fichier) !

Conclusion : L'utilisation fréquente de la fonction FileFlush ou son utilisation dans des boucles, pour accélérer le travail avec le fichier, donnera juste le résultat opposé, parce qu'à chaque appel, le système doit calculer la quantité d'information, réellement contenue dans le tampon I/O, appeler le système d'exploitation et donner la commande pour écrire cette section de mémoire au fichier ! Par exemple, si la boucle écrit un octet dans le fichier et appelle immédiatement la fonction FileFlush, nous obtenons la manière la plus lente d'écrire sur le disque BACKGROUND ! !! ;)

Alors, quel est le moyen le plus rapide d'écrire dans un fichier ? Très simple ;) Ne faites pas l'idiot et torturez FileFlush :) Dans ce cas, vous bénéficiez d'un échange de données rapide entre FileWrite et le presse-papiers (la manipulation de la mémoire est la plus rapide). Le système surveille le débordement de ce tampon et, si nécessaire, transmet les données (l'opération la plus rapide avec un dispositif aussi maladroit qu'un disque dur !) et vide le tampon pour recevoir de nouvelles données !

La question se pose alors : "Pourquoi avez-vous besoin de la fonction FileFlush ? ??". Et la réponse est simple : elle est nécessaire lorsque vous avez besoin que les données soient physiquement écrites dans le fichier, indépendamment du remplissage de la mémoire tampon. J'ai donné un exemple d'une telle nécessité ci-dessus.

Документация по MQL5: Файловые операции / FileFlush
Документация по MQL5: Файловые операции / FileFlush
  • www.mql5.com
Файловые операции / FileFlush - Документация по MQL5
 

J'ai dû réécrire mon indicateur pour MQL5 et j'ai rencontré une sérieuse confusion :(

Voici le code :

  first_bar=ChartGetInteger(0,CHART_FIRST_VISIBLE_BAR,0);
  
  //--- установим доступ к массиву как к таймсерии
  ResetLastError();
  int copied=CopyTime(NULL,0,0,first_bar,TimeAsSeries);
  del();
  int handle=FileOpen("Price Label\\"+_Symbol+tpl_ext,FILE_READ|FILE_CSV,';',CP_ACP);
  int er=GetLastError();
  ResetLastError();
  
  string sTF="";
  int TF;
  string period_name;
  string price_label;
  string price1;
  string price2;
  
  if (handle>=1){
    while(FileIsEnding(handle)==false){
      sTF = FileReadString(handle);
      TF = ResolveTF(sTF);
      period_name=FileReadString(handle);
      price_label=FileReadString(handle);
      price1=FileReadString(handle);
      price2=FileReadString(handle);
      drawe_price(TF,handle,period_name,price_label,price1,price2);
    }
    FileClose(handle);
  }
  return(0);

Je tiens à expliquer tout de suite que j'ai saisi un si grand nombre de variables pour voir ce qui se passe dans le débogueur. Et j'ai vu...

Le fichier contient un groupe de chaînes de caractères, chaque chaîne a 5 sections divisées par " ;". Le premier appel

sTF = FileReadString(handle);

met le fichier entier dans la variable STF, dans un encodage incompréhensible. A en juger par ce que je vois dans le débogueur (dans la variable STF, il lit le contenu du fichier en unicode ! En ouvrant le fichier, j'ai essayé toutes les pages de code disponibles, mais le résultat est le même :( Le fichier lui-même est écrit en encodage Windows.

Est-ce que quelqu'un a une idée de l'endroit où le chien est enterré ?

Документация по MQL5: Файловые операции / FileOpen
Документация по MQL5: Файловые операции / FileOpen
  • www.mql5.com
Файловые операции / FileOpen - Документация по MQL5
 

est_vale

Merci à tous de partager ces informations ! Je vais me plonger à nouveau dans le sujet.

  
FILE_ANSI
 
is_vale:

Quelqu'un a-t-il une idée de l'origine du problème ?

Je n'ai pas travaillé avec des opérations de fichiers depuis longtemps... Regardez, en utilisant FileOpen() vous avez un fichier CSV déclaré. Il permet de spécifier que tous les éléments écrits sont convertis en chaînes unicode ou ansi. Peut-être que c'est là que se trouve le chien ?

123456789
Nouveau commentaire
Raison: