Come è stato 'creato' un file nel 1641?

75

Qualche anno fa mi sono imbattuto in questo file sul nostro fileserver.

E mi chiedo come può un file dire che è stato creato nel 1641? Per quanto ne so, il tempo sul pc è definito dal numero di secondi dal 1 ° gennaio 1970. Se quell'indice si guasta, è possibile ottenere il 31 dic 1969 (l'indice probabilmente dice -1) ma sono sconcertato per questo data apparentemente casuale, che precede persino la fondazione degli Stati Uniti d'America.

Quindi, come potrebbe essere datato un file nel 1641?

PS: Le date sono in francese. Février è febbraio.

filesystems

— Fredy31
fonte

29

"Per quanto ne so, il tempo su PC è definito dal numero di secondi dal 1 ° gennaio 1970." - Anche per i sistemi in cui si trova, le date precedenti al 1970 sono facilmente rappresentate rendendo negativo quel numero (noto come timestamp unix ). Ad esempio, il tempo unix -1000000000 corrisponde a 1938-04-24 22:33:20.

— marcelm

1

@marcelm Sì, ma la data minima possibile è nel 1901 a causa della gamma limitata di numeri interi a 32 bit.

— slhck,

14

@slhck: Penso che marcelm stia assumendo un timestamp a 64 bit, perché è quello che usano gli attuali filesystem Unix / Linux, i kernel e il software dello spazio utente. Vedi la clock_gettime(2)pagina man per una definizione di struct timespec, che è ciò che state le altre chiamate di sistema usano per passare i timestamp tra spazio utente e kernel. È una struttura con a time_tin secondi e long tv_nsecnanosecondi. Sui sistemi a 64 bit, entrambi sono a 64 bit, quindi l'intero timestamp è di 128 bit (16 byte). (Mi dispiace per troppi dettagli, mi sono lasciato trasportare.)

— Peter Cordes,

3

Hai una buona risposta a come una data nel 1600 può essere timbrata nel file, ora è il momento di meditare su come è successo. Esaminerei molto attentamente il contenuto di quel file wp per vedere cosa avrebbe potuto essere aggiunto, in quanto ciò potrebbe far luce su come è successo. Guarderei i plugin installati e convaliderei che nessuno sia losco. Sto pensando a qualcosa che ha modificato quel file e ho provato a timbrare manualmente le date modificate / create per nascondere che il file è stato modificato ma ha specificato un tempo unix anziché un orario di Windows.

— Thomas Carlisle,

2

Il re Luigi XIII il Giusto stava dimostrando l'impegno della linea reale nei confronti di PHP?

— Jesse Slicer,

106

Perché è possibile una data del 1600?

Windows non memorizza i timestamp di modifica dei file come fanno i sistemi Unix . Secondo Windows Dev Center (l'enfasi è mia):

Un tempo di file è un valore a 64 bit che rappresenta il numero di intervalli di 100 nanosecondi che sono trascorsi dalle 12:00 AM 1 gennaio 1601 Coordinated Universal Time (UTC). Il sistema registra i tempi dei file quando le applicazioni creano, accedono e scrivono nei file.

Quindi, impostando un valore errato qui, puoi facilmente ottenere date dal 1600.

Naturalmente, un'altra domanda importante è: come è stato impostato questo valore? Qual è la data effettiva? Penso che non sarai mai in grado di scoprirlo, dato che avrebbe potuto essere semplicemente un errore di calcolo nel driver del file system. Un'altra risposta ipotizza che la data sia in realtà un timestamp Unix interpretato come un timestamp di Windows, ma in realtà sono calcolati su intervalli diversi (secondi vs nanosecondi).

In che modo ciò si collega al problema dell'anno 2038?

L'uso di un tipo di dati a 64 bit significa che Windows (in genere) non è interessato dal problema dell'anno 2038 che i sistemi Unix tradizionali hanno, poiché Unix inizialmente utilizzava un numero intero a 32 bit, che trabocca prima dell'intero a 64 bit che Windows ha. (Questo nonostante Unix operi in pochi secondi e Windows operi in micro / nanosecondi.)

Windows è ancora interessato quando si usano programmi a 32 bit che sono stati compilati con le vecchie versioni di Visual Studio, ovviamente.

I sistemi operativi Unix più recenti hanno già esteso il tipo di dati a 64 bit, evitando così il problema. (Infatti, poiché i timestamp di Unix funzionano in pochi secondi, la nuova data avvolgente sarà tra 292 miliardi di anni.)

Qual è la data massima che può essere impostata?

Per i curiosi: ecco come calcolarlo:

Il numero di valori possibili in un numero intero a 64 bit è 2 ⁶³ - 1 = 9223372036854775807 .
Ogni segno di spunta rappresenta 100 nanosecondi, ovvero 0,1 µs o 0,0000001 s.
L'intervallo di tempo massimo sarebbe 9223372036854775807 ⨉ 0,0000001 s , quindi centinaia di miliardi di secondi.
Un'ora ha 3600 secondi, un giorno ha 86400 secondi e un anno ha 365 giorni, quindi ci sono 86400 ⨉ 365 s = 31536000 s in un anno. Questo è, ovviamente, solo una media, ignorando gli anni bisestili, i secondi bisestili o qualsiasi modifica del calendario che i futuri regimi postpocalittici potrebbero imporre sui restanti terrestri.
9223372036854775807 ⨉ 0,0000001 s / 31536000 s ≈ 29247 anni
@corsiKaspiega come possiamo sottrarre anni bisestili: 29247/365/4 ≈ 20
Quindi il tuo anno massimo è 1601 + 29247-20 = 30828 .

Alcune persone hanno effettivamente cercato di impostare questo e hanno escogitato lo stesso anno.

— slhck
fonte

7

Per la cronaca, Unix (o almeno Linux) ha già risolto il problema del 2038 per il kernel / filesystem su architetture a 64 bit in cui time_tè un tipo a 64 bit, quindi si spera che le applicazioni utilizzino time_tinvece di un tipo intero che è ancora a 32 bit e troncerebbe i timestamp ... Comunque, nel caso in cui qualcuno fosse curioso di sapere lo stato del problema, è per lo più risolto tranne che per i legacy a 32 bit. IDK se ARM a 32 bit sarà ancora rilevante nel 2038, ma questo forzerà almeno un cambiamento ABI. X86 a 32 bit è praticamente sparito nel mondo Unix; è solo Windows in cui il codice a 32 bit è ancora comune.

— Peter Cordes,

I commenti non sono per una discussione estesa; questa conversazione è stata spostata in chat .

— Journeyman Geek

1

Il tempo VMS è " un valore a 64 bit che rappresenta il numero di intervalli di 100 nanosecondi che sono trascorsi dal " 17 novembre 1858. :)

— RonJohn

L'anno 30k è ... sorprendentemente basso

— John Dvorak

2

@DonaldDuck blogs.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913 e circa 1600 persone stavano ancora usando il calendario giuliano per rendere più complicata la rappresentazione di qualsiasi data precedente.

— Maciej Piechotka,

16

Se non ti senti male per qualche ipotesi, lasciami offrire una spiegazione. E non intendo "qualcuno ha impostato il valore su un non senso", ovviamente è sempre possibile :)

Il tempo di Unix di solito utilizza il numero di secondi dal 1970. Windows, d'altra parte, utilizza il 1601 come anno iniziale. Quindi, se assumiamo (e questo è un grande presupposto!) Che il problema è la conversione errata tra le due volte, possiamo immaginare che la data che doveva essere rappresentata sia in realtà ~~un giorno nel 2011 (1970 + 41), che è stata erroneamente convertita al 1640 (1601 + 41)~~ . EDIT: In realtà, ho fatto un errore nell'anno di Windows a partire. È possibile che il tempo di creazione effettivo sia stato nel 2010 o che si sia verificato un altro errore (gli errori off-by-one sono piuttosto comuni nel software: D).

Dato che quest'anno sembra essere un'altra delle date di tracciamento associate al file in questione, penso che sia una spiegazione abbastanza plausibile :)

— Luaan
fonte

Quindi potrebbe essere che la data sia stata scritta in Unix, ma sia letta in UTC?

— Fredy31,

Windows utilizza il 1601, non il 1600.

— Joey,

3

Alcuni problemi con questa teoria: secondo lo screenshot, il file sarebbe stato creato 11 giorni dopo l'ultimo accesso. Inoltre, i timestamp di Windows vengono conteggiati in 100 nanosecondi, mentre il tempo UNIX è in secondi.

— Nolonar,

2

@Joey Ugh, errore mio. Ciò rende la misura molto peggiore di quanto non sembri a prima vista :) Penso che la stessa idea di base dovrebbe ancora funzionare, ma probabilmente ci sono più errori di quanti ne pensassi. O, ovviamente, il file è stato creato nel 2010, non nel 2011.

— Luaan,

2

I secondi tra l'epoca di Windows e la data / ora del file mostrato sono 1.266.705.294 . Se aggiunto all'epoca di Unix, questo produce 2010-02-20 23:34:54 CEST , che era un sabato.

— SQB

5

Come è stato scritto da altri, l'epoca di Windows è alle 1601-01-01 00:00 .

Il numero di secondi tra quell'epoca e il tempo di permanenza visualizzato è 1.266.705.294 .
Se lo aggiungiamo all'epoca di Unix, arriveremo al 20/02/2010 alle 23:34:54 CEST , un sabato. Questo è circa un anno prima dell'ultima data di accesso, il che lo rende in qualche modo plausibile. Quindi potrebbe essere stato un timestamp Unix interpretato contro un'epoca sbagliata.

— SQB
fonte

Stranamente, l'epoca di .NET è 0001-01-01 00:00 UTC (che è 1600 anni prima). Vedi msdn.microsoft.com/en-us/library/…

— Nayuki

2

Come di consueto per questo tipo di domande, il blog di Raymond Chen ha una risposta al riguardo da "Perché è l'epoca di Win32 il 1 ° gennaio 1601?" ingresso dal 6 marzo 2009:

La FILETIMEstruttura registra il tempo sotto forma di intervalli di 100 nanosecondi dal 1 ° gennaio 1601. Perché è stata scelta quella data?

Il calendario gregoriano funziona su un ciclo di 400 anni e il 1601 è il primo anno del ciclo che era attivo al momento della progettazione di Windows NT. In altre parole, è stato scelto per far uscire bene la matematica.

In realtà ho l'e-mail di Dave Cutler che lo conferma.

— ErikF
fonte