Tive um problema aqui em um procedimento que faz algumas verificações de arquivos nas máquinas dos usuários. Para não dar nada, eram usuários daquele sistema operacional legal que insiste em nos dar algumas surpresinhas malucas de vez em quando. Eu achei estranho, fui dar uma fuçada para ver qual era a razão do problema e encontrei uma situação bem interessante. Vamos levar em conta o seguinte programa simples em C chamado conf.c:

 1 #include <time.h>
 2 #include <stdio.h>
 3 #include <stdlib.h>
 4 #include <sys/stat.h>
 5 
 6 int main(int argc, char** argv){
 7    struct stat   stDir;
 8    if(argc<2)
 9       exit(1);
10 
11    printf("Checando %s\n",argv[1]);
12    if(stat(argv[1],&stDir)<0)
13       exit(1);
14 
15    printf("%ld %s\n",stDir.st_ctime,ctime(&stDir.st_ctime));
16    return 0;
17 }

Esse programa faz uma coisa bem simples: verifica a data e hora da última alteração do status de um arquivo (ou um diretório) usando a função stat, que retorna algumas informações na estrutura stat, de onde eu formato a data de criação do arquivo usando a função ctime. Nada de complicado. Rodando esse programa no GNU/Linux duas vezes, alterando a data para uma data dentro do horário de verão entre as chamadas, tenho o seguinte resultado:

[taq@taq~]$ date
Ter Out 14 09:51:30 BRT 2008
[taq@taq~]$ conf .mozilla/
Checando .mozilla/
1205268188 Tue Mar 11 17:43:08 2008

[taq@taq~]$ date
Sáb Out 25 12:00:03 BRST 2008
[taq@taq~]$ conf .mozilla/
Checando .mozilla/
1205268188 Tue Mar 11 17:43:08 2008

Ok, o meu diretório ~/.mozilla foi criado em 11/03/2008 17:43:08, que foi comprovado em ambas as chamadas. Agora vou fazer a mesma coisa no "outro sistema":

C:\>date
Data atual: ter 14/10/2008
Digite a nova data: (dd-mm-aa)

C:\>conf c:\windows\temp
Checando c:\windows\temp
1201084518 Wed Jan 23 08:35:18 2008

C:\>date
Data atual: sáb 25/10/2008
Digite a nova data: (dd-mm-aa)

C:\>conf c:\windows\temp
Checando c:\windows\temp
1201088118 Wed Jan 23 09:35:18 2008

Uai! Alterando a data para uma dentro do horário de verão, a data do arquivo retornada muda também? Achei a causa do problema na verificação dos arquivos! O timestamp original do arquivo nunca vai bater com o retornado atualmente.

Qual é a razão disso eu ainda não entendi direito. IMHO o retorno da data do arquivo não deveria ser alterada nunca e o procedimento do GNU/Linux é que está correto, pois independente da situação corrente o arquivo foi criado em uma determinada data e hora, que no segundo caso era 23/01/2008 08:35:18. Fica aí a dica se alguém tiver algum problema do tipo.

Outra dica: se alguém precisar usar o gcc para o segundo teste, pode utilizar o MingW. O programa compila de boa utilizando gcc -o conf.exe -Wall -D_GNU_SOURCE conf.c.

Comentários

Comentários fechados.

• Daniel Luz seg, 01 de dezembro de 2008, 01:42:01 -0200

  Chegando bem atrasado… mas sim, esse é um clássico do Windows: datas no NTFS são convertidas transparentemente para UTC (sem guardar quaisquer informações auxiliares), e o resultado é que entrando no horário de verão seu sistema de arquivos inteiro automagicamente viaja no tempo.

• Andre Ferraz seg, 20 de outubro de 2008, 04:03:18 -0200

  Que Bizarro ! :D
  Sera que o modo que o sistema guarda em 'inode fat32/ntfs' as datas de modificação podem influenciar esse resultado ?

• Ataliba ter, 14 de outubro de 2008, 08:57:49 -0300

  Bizarro isto mesmo. Até porque isto vale inclusive para detonar uma perícia feita em um sistema operacional dentro um tribunal hahaha ou seja, o sistema de arquivos da M$ simplesmente não grava a hora real na qual o arquivo foi gravado.