Trabalhar com ficheiros. - página 5

[TheXpert]

Yedelkin:

Pergunta 1: Acha que há uma gralha na documentação, e que em vez de "Last Read Date" deveria dizer algo como "Last Open Date"?

Sim, aqui está o textual:

lpLastAccessTime [out, opcional]

Um ponteiro para uma estruturaFILETIME para receber a data e hora em que o ficheiro ou directório foi acedido pela última vez. O último tempo de acesso inclui a última vez que o ficheiro ou directório foi escrito, lido, ou, no caso de ficheiros executáveis, executado.

Tradução solta -- o último acesso inclui a última vez que o ficheiro foi lido ou escrito ou executado (se executável).

Provavelmente estou errado sobre a substituição do manípulo, mas há também este interessante texto:

Nem todos os sistemas de ficheiros podem registar a criação e os últimos tempos de acesso e nem todos os sistemas de ficheiros os registam da mesma forma. Por exemplo, no FAT, criar tempo tem uma resolução de 10 milissegundos, o tempo de escrita tem uma resolução de 2 segundos, e o tempo de acesso tem uma resolução de 1 dia (na realidade, a data de acesso). Portanto, a funçãoGetFileTime pode não devolver o mesmo conjunto de informações de tempo de arquivo usando a função SetFileTime.

NTFS atrasa as actualizações do último tempo de acesso de um ficheiro até uma hora após o último acesso. O NTFS também permite que as últimas actualizações do tempo de acesso sejam desactivadas. O último tempo de acesso não é actualizado nos volumes NTFS por defeito.

Na situação actual, a felicidade é esperada quando as propriedades do ficheiro são recuperadas sem "reabrir" a pega.

Aparentemente, sem sorte, pelo menos não quando se trata de segundos.

[Yedelkin]

TheXpert:

Sim, aqui está o textual:

Tradução solta -- o último acesso inclui a última vez que o ficheiro foi lido ou escrito ou executado (se executável).

Provavelmente estou errado sobre a substituição do manípulo, mas há também este interessante texto:

Aparentemente não existe tal sorte, pelo menos não quando se trata de segundos.

Obrigado pela ampliação da mente! Sim... Que chatice.

Este script diz que em vez de "Last read date" o identificador FILE_ACCESS_DATE retorna a hora do fecho do último ficheiro:

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);
     }
  }

[Yedelkin]

TheXpert:

Mas apesar das conclusões selvagens, os testes são reveladores, pelo que aguardamos os comentários dos programadores sobre o funcionamento da função quando não há mudanças.

A propósito, nos últimos três meses não recebi quaisquer comentários, por isso evito, por enquanto, utilizarFileFlush().

[Михаил Янович]

Parece-me que FileFlush não deve abrandar/acelerar o programa se este for utilizado em vez de FileClose.

Apenas não faz sentido utilizá-lo em loop para cada registo. Imagine quão lento seria o Word se fosse guardado de novo cada vez que um documento fosse modificado (especialmente se esse documento tiver muito texto e imagens). FileFLush só facilita salvar sem fechar ficheiros.

Os criadores devem ter significado que (Por exemplo):

OnInit - FileOpen

On Tick - FileWrite FileFlush

(e aqui os dados são guardados -FileFlash - no laço, não em cada passagem do laço, mas após o laço estar terminado)

OnDeinit FileClose.

O objectivo do FileFlash é escrever a ele o tempo todo que o Expert Advisor estiver a correr, para que não se reinicialize constantemente a manipulação do ficheiro e o buffer místico do ficheiro.

......niverso)

[TheXpert]

Yedelkin:
A propósito, não recebi quaisquer comentários nos últimos três meses, por isso evitei por enquanto a utilização de FileFlush().

De qualquer forma, não garante uma poupança imediata. Portanto, só faz sentido usá-lo para salvar o estado actual sem fechar a pega.

[is_vale]

Yedelkin:

A propósito, não tenho recebido quaisquer comentários nos últimos três meses, por isso evito por enquanto utilizar FileFlush().

Para compreender melhor o significado da função FileFlush(), precisamos de pensar sobre o conceito de buffer de entrada/saída de ficheiros... Como sabe, a informação em disco é armazenada em bytes e escrever cada byte individualmente (à medida que chegam) é a altura do desperdício! Se olhar para este processo pelo lado do "hardware", então a cada pedido de uma operação de byte-escrita, o sistema operativo teria de "abanar a cabeça do escritor" da unidade de disco rígido! E um disco rígido é cinemático! Por outras palavras, é o mais lento de todos os dispositivos informáticos. Então, qual é a solução? Uma solução muito simples! Na memória do computador é criado um buffer de dados (normalmente são algumas dezenas de kilobytes) no qual são enviados dados da função FileWrite e semelhantes a ele. Assim que este buffer for completamente preenchido, o sistema grava-o completamente num disco rígido como o bloco contínuo de dados, assim não é efectuada uma manipulação desnecessária da cabeça do disco, e simplesmente os dados são escritos em UM BLOCO! Calcular agora quantas vezes a velocidade de escrever 32 kilobytes de informação de cada vez aumenta em comparação com escrever cada byte separadamente do mesmo tamanho ;) E o cálculo é bastante simples... Para cada operação de escrita, a cabeça de accionamento é posicionada primeiro, depois é realizada a operação de escrita. E isso sem entrar em todo o trabalho árduo de uma operação de leitura/escrita :) No caso de um tampão, posicionamos a cabeça da unidade uma vez e escrevemos o bloco inteiro num só fluxo!

Mas tudo o que foi dito, até que o seu buffer esteja cheio, os seus dados não aparecerão fisicamente no ficheiro (!!!), ou até que feche o próprio ficheiro, caso em que o buffer (ou melhor, o que resta nele) é gravado imediatamente no disco. É aqui que entra a função FileFlush. Quando "escreveu" alguma informação para o ficheiro e precisa dela para aparecer no ficheiro (por exemplo, esta informação já pode ser utilizada por outro programa, indicador, Expert Advisor...), então pode chamar a função FileFlush, que descarregará fisicamente o conteúdo do buffer para o disco (para um ficheiro)!

Conclusão: A utilização frequente da função FileFlush ou a sua utilização em loops, para acelerar o trabalho com o ficheiro, dará exactamente o resultado oposto, porque a cada chamada, o sistema precisa de calcular a quantidade de informação realmente contida no buffer I/O, ligar para o sistema operativo e dar o comando para escrever esta área de memória no ficheiro! Por exemplo, o laço escreve um byte no ficheiro e imediatamente chama a função FileFlush, obtemos a forma mais lenta de escrever em disco ANTECEDENTES!!! ;)

Então como é a forma mais rápida de escrever para um ficheiro? Muito simples ;) Não brincar e torturar FileFlush :) Neste caso, obtém-se uma rápida troca de dados entre FileWrite e clipboard (a manipulação da memória é a mais rápida). O sistema irá observar o transbordamento neste buffer e, se necessário, transmitir dados (a operação mais rápida com um dispositivo tão desajeitado como um disco rígido!) e limpar o buffer para receber novos dados!!!

Surge então a questão - "Porque precisa da função FileFlush??". E a resposta é simples - é necessária quando se precisa que os dados sejam fisicamente escritos no ficheiro, independentemente do preenchimento do buffer. Dei um exemplo de tal necessidade acima.

[is_vale]

Tive de reescrever o meu indicador para MQL5 e encontrei alguma confusão séria :(

Aqui está o código:

  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);

Quero explicar desde já que introduzi um número tão grande de variáveis para ver o que se passa no depurador. E eu vi...

O ficheiro contém um monte de cordas, cada cordão tem 5 secções divididas por ";". A primeira chamada

sTF = FileReadString(handle);

coloca o ficheiro inteiro na variável sTF, numa codificação incompreensível. A julgar pelo que vejo no debugger (na variável sTF lê o conteúdo do ficheiro como unicode! Ao abrir o ficheiro, tentei todas as páginas de código disponíveis, mas o resultado é o mesmo :( O ficheiro em si é escrito na codificação do Windows.

Alguém tem alguma ideia onde o cão está enterrado?

[Yedelkin]

is_vale

Obrigado a todos vós por partilharem a informação! Vou mergulhar de novo no tema.

[TheXpert]

FILE_ANSI

[Yedelkin]

is_vale:

Alguém tem alguma ideia de onde reside o problema?

Já não trabalho com operações de arquivo há muito tempo. Olha, ao utilizar FileOpen() tem um ficheiro CSV declarado. Costumava especificar que todos os artigos escritos são convertidos em unicode ou ansi strings. Talvez seja aqui que o cão está?