Comment un fichier a-t-il pu être "créé" en 1641?


75

Il y a quelques années, je suis tombé sur ce fichier sur notre serveur de fichiers.

Capture d'écran d'une boîte de dialogue de propriétés de fichier dans Microsoft Windows

Et je me demande comment un fichier peut dire qu'il a été créé en 1641? Autant que je sache, le temps passé sur pc est défini par le nombre de secondes écoulées depuis le 1er janvier 1970. Si cet index vous échappe, vous pouvez obtenir le 31 décembre 1969 (l'indice indique probablement -1), mais je suis perplexe à ce sujet. date apparemment aléatoire, même avant la fondation des États-Unis d’Amérique.

Alors, comment un fichier pourrait-il être daté de 1641?

PS: les dates sont en français. Février est février.


29
"Pour autant que je sache, le temps sur pc est défini par le nombre de secondes depuis le 1er janvier 1970." - Même pour les systèmes où il se trouve, les dates antérieures à 1970 sont facilement représentées en rendant ce nombre (appelé horodatage Unix ) négatif. Par exemple, l'heure unix -1000000000 correspond à 1938-04-24 22:33:20.
marcelm

1
@marcelm Oui, mais la date minimale possible est en 1901 en raison de la plage limitée des entiers 32 bits.
Slhck

14
@slhck: Je pense que Marcel supposait un horodatage 64 bits, car c'est l'utilisation actuelle des systèmes de fichiers Unix / Linux, des noyaux et des logiciels d'espace utilisateur. Reportez-vous à la clock_gettime(2)page de manuel pour obtenir une définition de struct timespecce qui est ce statque d'autres appels système utilisent pour transmettre les horodatages entre l'espace utilisateur et le noyau. C'est une structure avec un time_ten secondes et une long tv_nsecnanosecondes. Sur les systèmes 64 bits, les deux sont en 64 bits, donc l'horodatage total est de 128 bits (16 octets). (Désolé pour trop de détails, je me suis emporté.)
Peter Cordes

3
Vous avez une bonne réponse sur la manière dont une date datant des années 1600 peut être inscrite dans le fichier. Il est maintenant temps de réfléchir à la façon dont cela s'est passé. Je regarderais de très près le contenu de ce fichier wp pour voir ce qui aurait pu être ajouté, car cela pourrait nous éclairer sur la façon dont cela s'est passé. Je regarderais les plugins installés et n'en validerais aucun. Je pense que quelque chose a modifié ce fichier et a essayé d'estamper manuellement des dates modifiées / créées pour masquer le fait que le fichier a été modifié mais a spécifié une heure Unix au lieu d'une heure Windows.
Thomas Carlisle

2
Le roi Louis XIII le Juste démontrait-il l'engagement de la ligne royale envers PHP?
Jesse Slicer

Réponses:


106

Pourquoi une date des années 1600 est-elle possible?

Windows ne stocke pas les horodatages de modification de fichiers, contrairement aux systèmes Unix . Selon le centre de développement Windows (emphase moi):

Une heure de fichier est une valeur de 64 bits représentant le nombre d' intervalles de 100 nanosecondes qui se sont écoulés depuis 00h00 le 1er janvier à 16 h 01, heure normale de la coordination (UTC). Le système enregistre les temps de fichier lorsque les applications créent, accèdent et écrivent dans des fichiers.

Donc, en définissant une mauvaise valeur ici, vous pouvez facilement obtenir les dates des années 1600.

Bien sûr, une autre question importante est: comment cette valeur a-t-elle été définie? Quelle est la date actuelle? Je pense que vous ne pourrez jamais le savoir, car cela aurait pu être simplement une erreur de calcul dans le pilote du système de fichiers. Une autre réponse suppose que la date est en réalité un horodatage Unix interprété comme un horodatage Windows, mais qu’il est en fait calculé à des intervalles différents (secondes par rapport aux nanosecondes).

Comment cela est-il lié au problème de l'année 2038?

L'utilisation d'un type de données 64 bits signifie que Windows (en général) n'est pas concerné par le problème de l' an 2038, car les systèmes Unix traditionnels ont déjà utilisé un entier 32 bits, qui déborde plus tôt que l'entier 64 bits défini par Windows. a. (Ceci malgré le système Unix fonctionnant sur secondes et Windows fonctionnant sur micro / nanosecondes.)

Windows est toujours concerné par les programmes 32 bits compilés avec les anciennes versions de Visual Studio, bien sûr.

Les systèmes d'exploitation Unix plus récents ont déjà étendu le type de données à 64 bits, évitant ainsi le problème. (En fait, étant donné que les horodatages Unix fonctionnent en quelques secondes, la nouvelle date enveloppante sera dans 292 milliards d’années.)

Quelle est la date maximum pouvant être définie?

Pour les curieux, voici comment calculer cela:

  • Le nombre de valeurs possibles dans un entier 64 bits est compris entre 2 63 - 1 = 9223372036854775807 .
  • Chaque tick correspond à 100 nanosecondes, soit 0,1 µs ou 0,0000001 s.
  • La plage de temps maximale serait de 9223372036854775807 ⨉ 0.0000001 s , soit des centaines de milliards de secondes.
  • Une heure a 3 600 secondes, un jour, 86 400 secondes et un an, 365 jours. Il y a donc 86 400 × 365 s = 31536000 s par an. Ceci, bien sûr, n’est qu’une moyenne, ignorant les années bissextiles, les secondes intercalaires ou tout changement de calendrier que les futurs régimes postapocalyptiques pourraient imposer aux terriens restants.
  • 9223372036854775807 ⨉ 0,0000001 s / 31536000 s ≈ 29247 ans
  • @corsiKaexplique comment soustraire des années bissextiles: 29247/365/4 20
  • Donc, votre année maximum est 1601 + 29247 - 20 = 30828 .

Certaines personnes ont en fait essayé de définir cela et ont présenté la même année.


7
Pour mémoire, Unix (ou au moins Linux) a déjà résolu le problème 2038 pour le noyau / les systèmes de fichiers sur les architectures 64 bits où il time_ts’agit d’un type 64 time_tbits. tronquerait les horodatages ... Quoi qu'il en soit, si quelqu'un était curieux de connaître l'état du problème, il est en grande partie résolu, à l'exception de l'ancienne version 32 bits. IDK si ARM 32 bits sera toujours pertinent en 2038, mais cela obligera au moins un changement ABI. Le x86 32 bits est quasiment disparu dans le monde Unix; ce n'est que Windows où le code 32 bits est encore courant.
Peter Cordes

Les commentaires ne sont pas pour une discussion prolongée; cette conversation a été déplacée pour discuter .
Compagnon Geek

1
L'heure VMS est " une valeur de 64 bits qui représente le nombre d'intervalles de 100 nanosecondes qui se sont écoulés depuis " le 17 novembre 1858. :)
RonJohn

L'année 30k est ... étonnamment basse
John Dvorak

2
@DonaldDuck blogs.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913 et environ 1 600 personnes utilisaient encore le calendrier Julian pour rendre la représentation d'une date antérieure à celle plus compliquée.
Maciej Piechotka

16

Si vous ne vous sentez pas trop mal à propos de certaines suppositions, laissez-moi vous expliquer. Et je ne veux pas dire "quelqu'un définit la valeur comme un non-sens", c'est évidemment toujours possible :)

Le temps Unix utilise généralement le nombre de secondes depuis 1970. Windows, en revanche, utilise 1601 comme année de début. Donc, si nous supposons (et c'est une grosse hypothèse!) Que le problème est une conversion erronée entre les deux temps, nous pouvons imaginer que la date qui était censée être représentée est en fait en 2011 (1970 + 41), qui a été mal convertie à 1640 (1601 + 41) . EDIT: En fait, j'ai commis une erreur lors de la première année Windows. Il est possible que la création ait eu lieu en 2010 ou qu'il y ait eu une autre erreur (les erreurs off-by-one sont assez courantes dans les logiciels: D).

Étant donné que cette année est une autre des dates de suivi associées au fichier en question, je pense que c'est une explication assez plausible :)


Donc, il se pourrait que la date ait été écrite sous Unix, mais est-elle lue en UTC?
Fredy31

Windows utilise 1601, pas 1600.
Joey

3
Quelques problèmes avec cette théorie: selon la capture d'écran, le fichier aurait été créé 11 jours après son dernier accès. En outre, les horodatages Windows sont comptés en 100 nanosecondes, tandis que le temps UNIX est en secondes.
Nolonar

2
@ Joey Ugh, mon erreur. Cela rend la situation bien pire qu'au premier abord :) Je pense que la même idée de base devrait toujours fonctionner, mais il y a probablement plus d'erreurs impliquées que je ne le supposais. Ou bien sûr, le fichier a été créé en 2010, pas en 2011.
Luaan

2
La seconde entre l’époque Windows et la date / heure indiquée est de 1.266.705.294 . Une fois ajouté à l'époque Unix, cela donne 2010-02-20 23:34:54 CEST , qui était un samedi.
SQB

5

Comme cela a été écrit par d’autres, l’époque Windows est le 1601-01-01 00:00 .

Le nombre de secondes entre cette époque et l’heure du fichier affiché est 1.266.705.294 .
Si nous ajoutons cela à l'époque Unix, nous arrivons au 2010-02-20 23:34:54 CEST , un samedi. C'est environ un an avant la dernière date d'accès, ce qui le rend un peu plausible. Il s’agissait donc peut-être d’un horodatage Unix interprété contre la mauvaise époque.


Curieusement, l’époque .NET est 0001-01-01 00:00 UTC (1600 ans plus tôt). Voir msdn.microsoft.com/en-us/library/…
Nayuki

2

Comme d'habitude pour ce genre de questions, le blog de Raymond Chen a une réponse à ce sujet dans "Pourquoi l'époque Win32 du 1er janvier 1601?" entrée du 6 mars 2009:

La FILETIMEstructure enregistre le temps sous forme d'intervalles de 100 nanosecondes depuis le 1er janvier 1601. Pourquoi cette date a-t-elle été choisie?

Le calendrier grégorien fonctionne sur un cycle de 400 ans et 1601 est la première année du cycle qui était actif au moment de la conception de Windows NT. En d'autres termes, il a été choisi pour que les calculs soient bien faits.

En fait, le courrier électronique de Dave Cutler le confirme.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.