Como um arquivo pode ser 'criado' em 1641?

75

Alguns anos atrás, deparei com este arquivo em nosso servidor de arquivos.

E eu me pergunto como um arquivo pode dizer que foi criado em 1641? Até onde eu sei, o tempo no pc é definido pelo número de segundos desde 1º de janeiro de 1970. Se esse índice falha, você pode obter 31 de dezembro de 1969 (o índice provavelmente diz -1), mas estou perplexo com isso. data aparentemente aleatória, que antecede até a fundação dos Estados Unidos da América.

Então, como um arquivo poderia ser datado em 1641?

PS: As datas são em francês. Février é fevereiro.

filesystems

— Fredy31
fonte

29

"Até onde eu sei, o tempo no PC é definido pelo número de segundos desde 1º de janeiro de 1970." - Mesmo para sistemas onde estão, as datas anteriores a 1970 são facilmente representadas, tornando esse número (conhecido como registro de data e hora unix ) negativo. Por exemplo, o tempo unix -1000000000 corresponde a 1938-04-24 22:33:20.

— marcelm

1

@ marcelm Sim, mas a data mínima possível existe em 1901 devido ao intervalo limitado de números inteiros de 32 bits.

— slhck

14

@slhck: Eu acho que o marcelm estava assumindo um registro de data e hora de 64 bits, porque é isso que os sistemas de arquivos, kernels e softwares atuais do Unix / Linux usam. Consulte a clock_gettime(2)página do manual para obter uma definição de struct timespecqual é o que state outras chamadas do sistema usam para passar carimbos de data e hora entre o espaço do usuário e o kernel. É uma estrutura com um time_tem segundos e um long tv_nsecnanossegundo. Nos sistemas de 64 bits, ambos são de 64 bits, portanto, todo o registro de data e hora é de 128 bits (16 bytes). (Desculpe por muitos detalhes, eu me empolguei.)

— Peter Cordes

3

Você tem uma boa resposta sobre como uma data nos anos 1600 pode ser carimbada no arquivo, agora é hora de refletir sobre como aconteceu. Eu examinaria o conteúdo desse arquivo wp com muita atenção para ver o que poderia ter sido adicionado, pois isso poderia esclarecer como isso aconteceu. Eu observaria os plugins instalados e validaria que nenhum deles é obscuro. Eu estou pensando que algo modificou esse arquivo e tentei carimbar manualmente datas modificadas / criadas para ocultar que o arquivo foi modificado, mas especificou uma hora unix em vez de uma hora do Windows.

— Thomas Carlisle

2

O rei Luís XIII, o Justo, estava demonstrando o compromisso da linha real com o PHP?

— precisa

106

Por que uma data do século XVII é possível?

O Windows não armazena registros de data e hora de modificação de arquivos, como os sistemas Unix . De acordo com o Windows Dev Center (ênfase minha):

Um horário do arquivo é um valor de 64 bits que representa o número de intervalos de 100 nanossegundos decorridos desde as 00:00 de 1º de janeiro de 1601, horário universal coordenado (UTC). O sistema registra os horários dos arquivos quando os aplicativos criam, acessam e gravam nos arquivos.

Portanto, definindo um valor errado aqui, você pode facilmente obter datas do século XVII.

Obviamente, outra questão importante é: como esse valor foi definido? Qual é a data real? Eu acho que você nunca será capaz de descobrir, pois isso poderia ter sido simplesmente um erro de cálculo no driver do sistema de arquivos. Outra resposta sugere que a data é realmente um carimbo de data / hora do Unix interpretado como um carimbo de data / hora do Windows, mas na verdade eles são calculados em intervalos diferentes (segundos vs. nanossegundos).

Como isso se relaciona com o problema do ano 2038?

O uso de um tipo de dados de 64 bits significa que o Windows (geralmente) não é afetado pelo Problema do Ano 2038 que os sistemas Unix tradicionais têm, pois o Unix usava inicialmente um número inteiro de 32 bits, que transborda mais cedo que o número inteiro de 64 bits que o Windows tem. (Isso ocorre apesar do Unix operar em segundos e do Windows operar em micro / nanossegundos.)

O Windows ainda é afetado ao usar programas de 32 bits que foram compilados com versões antigas do Visual Studio, é claro.

Os sistemas operacionais Unix mais recentes já expandiram o tipo de dados para 64 bits, evitando assim o problema. (De fato, como os carimbos de data e hora do Unix operam em segundos, a nova data abrangente será de 292 bilhões de anos a partir de agora.)

Qual é a data máxima que pode ser definida?

Para os curiosos - veja como calcular isso:

O número de valores possíveis em um número inteiro de 64 bits é 2 ⁶³ - 1 = 9223372036854775807 .
Cada marca representa 100 nanossegundos, ou seja, 0,1 µs ou 0,0000001 s.
O intervalo de tempo máximo seria 9223372036854775807 ± 0,0000001 s , portanto, centenas de bilhões de segundos.
Uma hora tem 3600 segundos, um dia tem 86400 segundos e um ano tem 365 dias; portanto, existem 86400 × 365 s = 31536000 s em um ano. É claro que isso é apenas uma média, ignorando anos bissextos, segundos bissextos ou qualquer mudança de calendário que futuros regimes pós-apocalípticos possam ditar nos demais terráqueos.
9223372036854775807 ⨉ 0,0000001 s / 31536000 s ≈ 29247 anos
@corsiKaexplica como podemos subtrair anos bissextos: 29247/365/4 ≈ 20
Portanto, seu ano máximo é 1601 + 29247 - 20 = 30828 .

Algumas pessoas realmente tentaram definir isso e criaram o mesmo ano.

— slhck
fonte

7

Para o registro, o Unix (ou pelo menos Linux) já resolveu o problema de 2038 para o kernel / sistemas de arquivos em arquiteturas de 64 bits, onde time_té do tipo de 64 bits, portanto, esperamos que os aplicativos usem, em time_tvez de um tipo inteiro que ainda seja de 32 bits e truncaria os registros de data e hora ... De qualquer forma, caso alguém tenha curiosidade sobre o status do problema, ele será resolvido, exceto pelo legado de 32 bits. IDK se o ARM de 32 bits ainda for relevante em 2038, mas isso forçará pelo menos uma alteração ABI. O x86 de 32 bits já se foi no mundo Unix; é apenas no Windows onde o código de 32 bits ainda é comum.

— Peter Cordes

Comentários não são para discussão prolongada; esta conversa foi movida para o bate-papo .

— Journeyman Geek

1

O tempo do VMS é " um valor de 64 bits que representa o número de intervalos de 100 nanossegundos decorridos desde " 17 de novembro de 1858. :)

— RonJohn

30k ano é ... surpreendentemente baixo

— John Dvorak

2

O @DonaldDuck blogs.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913 e cerca de 1600 pessoas ainda estavam usando o calendário juliano, tornando a representação de qualquer data antes dessa data mais complicada.

— Maciej Piechotka 30/03/19

16

Se você não se sentir muito mal com algumas suposições, deixe-me dar uma explicação. E não quero dizer "alguém defina o valor como um absurdo", obviamente isso é sempre possível :)

O tempo Unix geralmente usa o número de segundos desde 1970. O Windows, por outro lado, usa 1601 como o ano inicial. Portanto, se assumirmos (e isso é uma grande suposição!) Que o problema está com uma conversão incorreta entre as duas vezes, podemos imaginar que a data que deveria ser representada é realmente ~~em algum momento de 2011 (1970 + 41), que foi convertido incorretamente a 1640 (1601 + 41)~~ . EDIT: Na verdade, eu cometi um erro no Windows a partir do ano. É possível que o tempo real de criação tenha sido em 2010 ou que tenha ocorrido outro erro (erros de um por um são bastante comuns no software: D).

Como este ano é outra das datas de rastreamento associadas ao arquivo em questão, acho que é uma explicação bastante plausível :)

— Luaan
fonte

Então pode ser que a data tenha sido escrita em Unix, mas seja lida em UTC?

— Fredy31

O Windows usa 1601, e não 1600.

— Joey

3

Alguns problemas com essa teoria: de acordo com a captura de tela, o arquivo teria sido criado 11 dias após o último acesso. Além disso, os carimbos de data e hora do Windows são contados em 100 nanossegundos, enquanto o tempo do UNIX é em segundos.

— Nolonar 28/03/19

2

@ Joey Ugh, meu erro. Isso torna o ajuste muito pior do que à primeira vista :) Acho que a mesma idéia básica ainda deve funcionar, mas provavelmente há mais erros envolvidos do que eu supus. Ou, é claro, o arquivo foi criado em 2010, e não em 2011.

— Luaan 28/18

2

Os segundos entre a época do Windows e a data / hora do arquivo mostrada são 1.266.705.294 . Quando adicionado à época do Unix, gera 20-02-2010 23:34:54 CEST , que era um sábado.

— SQB 29/03

5

Como foi escrito por outras pessoas, a época do Windows é 1601-01-01 00:00 .

O número de segundos entre a época e a hora do arquivo exibida é 1.266.705.294 .
Se adicionarmos isso à época do Unix, chegamos ao 20-02-2010 23:34:54 CEST , um sábado. Isso é cerca de um ano antes da última data de acesso, o que a torna um tanto plausível. Portanto, pode ter sido um carimbo de data / hora do Unix interpretado contra a época errada.

— SQB
fonte

Curiosamente, a época do .NET é 0001-01-01 00:00 UTC (que é 1600 anos antes). Consulte msdn.microsoft.com/en-us/library/…

— Nayuki

2

Como sempre, para esses tipos de perguntas, o blog de Raymond Chen tem uma resposta sobre isso em "Por que a época do Win32 é 1º de janeiro de 1601?" entrada de 6 de março de 2009:

A FILETIMEestrutura registra o tempo na forma de intervalos de 100 nanossegundos desde 1º de janeiro de 1601. Por que essa data foi escolhida?

O calendário gregoriano opera em um ciclo de 400 anos e 1601 é o primeiro ano do ciclo ativo no momento em que o Windows NT estava sendo projetado. Em outras palavras, foi escolhido para fazer a matemática sair bem.

Na verdade, tenho o e-mail de Dave Cutler confirmando isso.

— ErikF
fonte