¿Cómo se puede 'crear' un archivo en 1641?

75

Hace unos años, me topé con este archivo en nuestro servidor de archivos.

Y me pregunto cómo puede un archivo decir que se creó en 1641. Hasta donde sé, el tiempo en la PC se define por la cantidad de segundos desde el 1 de enero de 1970. Si ese índice falla, puede obtener el 31 de diciembre de 1969 (el índice probablemente dice -1) pero estoy perplejo por esto fecha aparentemente aleatoria, que es anterior incluso a la fundación de los Estados Unidos de América.

Entonces, ¿cómo podría fecharse un archivo en 1641?

PD: Las fechas son en francés. Février es febrero.

filesystems

— Fredy31
fuente

29

"Hasta donde yo sé, el tiempo en la PC se define por la cantidad de segundos desde el 1 de enero de 1970". - Incluso para sistemas donde está, las fechas anteriores a 1970 se representan fácilmente al hacer que ese número (conocido como marca de tiempo de Unix ) sea negativo. Por ejemplo, el tiempo unix -1000000000 corresponde a 1938-04-24 22:33:20.

— marcelm

1

@marcelm Sí, pero la fecha mínima posible es 1901 debido al rango limitado de enteros de 32 bits.

— slhck

14

@slhck: Creo que marcelm estaba asumiendo una marca de tiempo de 64 bits, porque eso es lo que usan los sistemas de archivos Unix / Linux, los núcleos y el software de espacio de usuario actuales. Consulte la clock_gettime(2)página de manual para obtener una definición de struct timespec, que es lo que statusan otras llamadas del sistema para pasar marcas de tiempo entre el espacio de usuario y el núcleo. Es una estructura con un time_ten segundos y un long tv_nsecnanosegundo. En los sistemas de 64 bits, ambos son de 64 bits, por lo que la marca de tiempo completa es de 128 bits (16 bytes). (Perdón por demasiados detalles, me dejé llevar.)

— Peter Cordes

3

Obtuviste una buena respuesta sobre cómo se puede estampar en el archivo una fecha en el siglo XVII, ahora es el momento de reflexionar sobre cómo sucedió. Miraría el contenido de ese archivo wp muy de cerca para ver qué podría haberse agregado, ya que eso podría arrojar luz sobre cómo sucedió. Vería los complementos instalados y validaría que ninguno sea sospechoso. Estoy pensando que algo modificó ese archivo e intenté marcar manualmente las fechas modificadas / creadas para ocultar que el archivo se modificó, pero especificó una hora de Unix en lugar de una hora de Windows.

— Thomas Carlisle

2

¿El rey Luis XIII el justo estaba demostrando el compromiso de la línea real con PHP?

— Jesse Slicer

106

¿Por qué es posible una fecha del 1600?

Windows no almacena marcas de tiempo de modificación de archivos como lo hacen los sistemas Unix . De acuerdo con el Centro de desarrollo de Windows (énfasis mío):

Un tiempo de archivo es un valor de 64 bits que representa el número de intervalos de 100 nanosegundos que han transcurrido desde las 12:00 a.m. del 1 de enero de 1601, hora universal coordinada (UTC). El sistema registra los tiempos de archivo cuando las aplicaciones crean, acceden y escriben en archivos.

Entonces, al establecer un valor incorrecto aquí, puede obtener fácilmente las fechas del 1600.

Por supuesto, otra pregunta importante es: ¿cómo se estableció este valor? ¿Cuál es la fecha real? Creo que nunca podrá averiguarlo, ya que podría haber sido simplemente un error de cálculo en el controlador del sistema de archivos. Otra respuesta supone que la fecha es en realidad una marca de tiempo de Unix interpretada como una marca de tiempo de Windows, pero en realidad se calculan en diferentes intervalos (segundos frente a nanosegundos).

¿Cómo se relaciona esto con el problema del año 2038?

El uso de un tipo de datos de 64 bits significa que Windows (en general) no se ve afectado por el problema del año 2038 que tienen los sistemas Unix tradicionales, ya que Unix inicialmente usó un número entero de 32 bits, que se desborda antes que el número entero de 64 bits que Windows tiene. (Esto es a pesar de que Unix funciona en segundos y Windows funciona en micro / nanosegundos).

Windows todavía se ve afectado cuando se utilizan programas de 32 bits que se compilaron con versiones antiguas de Visual Studio, por supuesto.

Los nuevos sistemas operativos Unix ya han ampliado el tipo de datos a 64 bits, evitando así el problema. (De hecho, dado que las marcas de tiempo Unix operan en segundos, la nueva fecha envolvente será de 292 mil millones de años a partir de ahora).

¿Cuál es la fecha máxima que se puede configurar?

Para los curiosos, aquí está cómo calcular eso:

El número de valores posibles en un entero de 64 bits son 2 ⁶³ - 1 = 9223372036854775807 .
Cada marca representa 100 nanosegundos, que es 0.1 µs o 0.0000001 s.
El rango de tiempo máximo sería 9223372036854775807 ⨉ 0.0000001 s , por lo que cientos de miles de millones de segundos.
Una hora tiene 3600 segundos, un día tiene 86400 segundos y un año tiene 365 días, por lo que hay 86400 ⨉ 365 s = 31536000 s en un año. Esto es, por supuesto, solo un promedio, ignorando los años bisiestos, los segundos bisiestos o cualquier cambio de calendario que los futuros regímenes postapocalípticos puedan dictar sobre los terrícolas restantes.
9223372036854775807 ⨉ 0.0000001 s / 31536000 s ≈ 29247 años
@corsiKaexplica cómo podemos restar los años bisiestos: 29247/365/4 ≈ 20
Entonces su año máximo es 1601 + 29247 - 20 = 30828 .

Algunas personas realmente han tratado de configurar esto y se le ocurrió el mismo año.

— slhck
fuente

77

Para el registro, Unix (o al menos Linux) ya ha resuelto el problema 2038 para el núcleo / sistemas de archivos en arquitecturas de 64 bits donde time_thay un tipo de 64 bits, por lo que es de esperar que las aplicaciones usen en time_tlugar de un tipo entero que todavía es de 32 bits y truncaría las marcas de tiempo ... De todos modos, en caso de que alguien tuviera curiosidad sobre el estado del problema, se resuelve principalmente, excepto por el legado de 32 bits. IDK si el ARM de 32 bits seguirá siendo relevante en 2038, pero esto forzará al menos un cambio de ABI. El x86 de 32 bits ya no existe en el mundo Unix; Es solo Windows donde el código de 32 bits sigue siendo común.

— Peter Cordes

Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .

— Journeyman Geek

1

El tiempo VMS es " un valor de 64 bits que representa el número de intervalos de 100 nanosegundos que han transcurrido desde " 17-nov-1858. :)

— RonJohn

Año 30k es ... sorprendentemente bajo

— John Dvorak

2

@DonaldDuck blogs.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913 y alrededor de 1600 personas todavía usaban el calendario juliano, lo que complicaba aún más la representación de cualquier fecha anterior.

— Maciej Piechotka

16

Si no te sientes mal por adivinar, déjame ofrecerte una explicación. Y no me refiero a "alguien establece el valor en tonterías", eso obviamente siempre es posible :)

El tiempo Unix usualmente usa la cantidad de segundos desde 1970. Windows, por otro lado, usa 1601 como año de inicio. Entonces, si suponemos (¡y eso es una gran suposición!) Que el problema es una conversión incorrecta entre las dos veces, podemos imaginar que la fecha que se suponía que estaba representada es en ~~algún momento en 2011 (1970 + 41), que se convirtió incorrectamente a 1640 (1601 + 41)~~ . EDITAR: En realidad, cometí un error en el año de inicio de Windows. Es posible que el tiempo de creación real fuera en 2010, o que hubiera otro error involucrado (los errores ocasionales son bastante comunes en el software: D).

Dado que este año es otra de las fechas de seguimiento asociadas con el archivo en cuestión, creo que es una explicación bastante plausible :)

— Luaan
fuente

Entonces, ¿podría ser que la fecha se escribió en Unix, pero se lee en UTC?

— Fredy31

Windows usa 1601, no 1600.

— Joey

3

Algunos problemas con esa teoría: según la captura de pantalla, el archivo se habría creado 11 días después de que se accedió por última vez. Además, las marcas de tiempo de Windows se cuentan en 100 nanosegundos, mientras que el tiempo UNIX es en segundos.

— Nolonar

2

@Joey Ugh, mi error. Eso hace que el ajuste sea mucho peor que a primera vista :) Creo que la misma idea básica aún debería funcionar, pero probablemente haya más errores involucrados de lo que supuse. O, por supuesto, el archivo se creó en 2010, no en 2011.

— Luaan

2

Los segundos entre la época de Windows y la fecha / hora del archivo mostrado son 1.266.705.294 . Cuando se agrega a la época de Unix, esto produce 2010-02-20 23:34:54 CEST , que fue un sábado.

— SQB

5

Como ha sido escrito por otros, la época de Windows es en 1601-01-01 00:00 .

El número de segundos entre esa época y el tiempo de archivo mostrado es 1.266.705.294 .
Si agregamos eso a la época de Unix, llegamos a 2010-02-20 23:34:54 CEST , un sábado. Esto es aproximadamente un año antes de la última fecha de acceso, lo que lo hace algo plausible. Por lo tanto, puede haber sido una marca de tiempo de Unix interpretada contra la época incorrecta.

— SQB
fuente

Por extraño que parezca, la época .NET es 0001-01-01 00:00 UTC (que es 1600 años antes). Ver msdn.microsoft.com/en-us/library/…

— Nayuki el

2

Como es habitual para este tipo de preguntas, el blog de Raymond Chen tiene una respuesta al respecto de "¿Por qué es la época de Win32 el 1 de enero de 1601?" Entrada a partir del 6 de marzo de 2009:

La FILETIMEestructura registra el tiempo en forma de intervalos de 100 nanosegundos desde el 1 de enero de 1601. ¿Por qué se eligió esa fecha?

El calendario gregoriano opera en un ciclo de 400 años, y 1601 es el primer año del ciclo que estaba activo en el momento en que se diseñó Windows NT. En otras palabras, fue elegido para que las matemáticas salgan bien.

De hecho, tengo el correo electrónico de Dave Cutler confirmando esto.

— ErikF
fuente