Question Comment un fichier peut-il avoir été "créé" en 1641?


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

Screenshot of a file properties dialog in Microsoft Windows

Et je me demande comment un fichier peut dire qu’il a été créé en 1641? Pour 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 indice se détache, vous pouvez obtenir le 31 décembre 1969 (l'index indique probablement -1), mais je suis perplexe à ce sujet. date apparemment aléatoire, qui précède même 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.


74
2018-03-27 14:33


origine


"Autant que je sache, le temps passé sur PC est défini par le nombre de secondes écoulées 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 par ce numéro (appelé horodatage unix) négatif. Par exemple, l'heure unix -1000000000 correspond à 1938-04-24 22:33:20. - marcelm
@marcelm Oui, mais la date minimale est en 1901 en raison de la gamme limitée d'entiers 32 bits. - slhck
@slhck: Je pense que marcelm supposait un horodatage de 64 bits, car c'est ce que les systèmes de fichiers, les noyaux et les logiciels d'espace utilisateur Unix / Linux actuels utilisent. Voir le clock_gettime(2) page de manuel pour une définition de struct timespec, lequel est quoi statet d'autres appels système utilisent pour passer des horodatages entre l'espace utilisateur et le noyau. C'est une structure avec un time_t en quelques secondes, et un long tv_nsec nanosecondes. Sur les systèmes 64 bits, les deux sont 64 bits, de sorte que l’horodatage total est de 128 bits (16 octets). (Désolé pour trop de détails, je me suis emporté.) - Peter Cordes
Vous avez une bonne réponse à la manière dont une date dans les années 1600 peut être apposée sur le fichier, maintenant il est temps de réfléchir à la façon dont cela s'est produit. Je regardais 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 manière dont cela s'est produit. Je regarderai les plugins installés et validerai qu'aucun n'est louche. Je pense que quelque chose a modifié ce fichier et a essayé de tamponner manuellement les dates modifiées / créées pour cacher que le fichier a été modifié mais a spécifié une heure unix au lieu d'une heure Windows. - Thomas Carlisle
Le roi Louis XIII le Juste était-il en train de démontrer l'engagement de la ligne royale envers PHP? - Jesse Slicer


Réponses:


Pourquoi une date du 1600 est-elle possible?

Windows ne stocke pas les horodatages de modification de fichier comme les systèmes Unix font. Selon le Centre de développement Windows (emphase la mienne):

Une heure de fichier est une valeur de 64 bits qui représente le nombre de 100 nanosecondes les intervalles écoulés depuis 12:00 AM 1er janvier 1601 Temps universel coordonné (UTC). Le système enregistre les heures de fichiers lorsque les applications créent, accèdent et écrivent des fichiers.

Ainsi, en définissant une mauvaise valeur ici, vous pouvez facilement obtenir des dates à partir des années 1600.

Bien sûr, une autre question importante est la suivante: comment cette valeur at-elle été définie? Quelle est la date réelle? 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 fait un timestamp Unix interprété comme un horodatage Windows, mais ils sont en réalité calculés à des intervalles différents (secondes vs nanosecondes).

Comment cela se rapporte-t-il au problème de l'an 2038?

L'utilisation d'un type de données 64 bits signifie que Windows (généralement) n'est pas affecté par Année 2038 Problème les systèmes Unix traditionnels, puisque Unix utilisait initialement un entier de 32 bits, qui déborde plus tôt que le nombre entier de 64 bits de Windows. (Malgré Unix fonctionnant en quelques secondes et Windows fonctionnant sur micro / nanosecondes.)

les fenêtres est toujours affecté bien sûr, lors de l’utilisation de programmes 32 bits compilés avec d’anciennes versions de Visual Studio.

Nouveaux systèmes d'exploitation Unix ont déjà élargi le type de données à 64 bits, évitant ainsi le problème. (En fait, comme les horodatages Unix fonctionnent en quelques secondes, la nouvelle date limite sera de 292 milliards d'années).

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

Pour les curieux, voici comment calculer cela:

  • le nombre de valeurs possibles dans un entier de 64 bits sont 263 - 1 = 9223372036854775807.
  • Chaque coche représente 100 nanosecondes, soit 0,1 µs ou 0,0000001 s.
  • La plage de temps maximale serait 9223372036854775807 ⨉ 0.0000001 s, donc des centaines de milliards de secondes.
  • Une heure a 3600 secondes, une journée 86400 secondes et une année 365 jours, donc il y a 86400 ⨉ 365 s = 31536000 s dans un an. Ce n'est, bien sûr, qu'une moyenne, en ignorant les années bissextiles, les secondes bissextiles ou tout changement de calendrier que les futurs régimes postapocalyptiques pourraient imposer aux autres terriens.
  • 9223372036854775807 ⨉ 0.0000001 s / 31536000 s ≈ 29247 ans
  • @corsiKa explique comment on peut soustraire les années bissextiles: 29247/365/4 ≈ 20
  • Donc, votre année maximum est 1601 + 29247 - 20 = 30828.

Certaines personnes ont effectivement essayé de définir cette et est venu avec la même année.


106
2018-03-27 14:41



Pour mémoire, Unix (ou au moins Linux) a déjà résolu le problème 2038 pour les systèmes de fichiers / noyau sur les architectures 64 bits où time_t est un type 64 bits, donc espérons que les applications utilisent time_t au lieu d'un type entier qui est toujours de 32 bits et qui tronquerait les horodatages ... Quoi qu'il en soit, au cas où quelqu'un serait curieux de connaître l'état du problème, il serait généralement résolu à l'exception de l'héritage 32 bits. IDK si ARM 32 bits sera toujours pertinent en 2038, mais cela forcera au moins un changement ABI. 32 bits x86 est pratiquement disparu dans le monde Unix; ce n'est que Windows où le code 32 bits est encore commun. - Peter Cordes
Les commentaires ne sont pas destinés à une discussion approfondie; cette conversation a été déplacé pour discuter. - Journeyman Geek♦
Le temps VMS est "une valeur de 64 bits représentant le nombre d'intervalles de 100 nanosecondes écoulés depuis"17-nov-1858. :) - RonJohn
Année 30k est ... étonnamment faible - John Dvorak
@DonaldDuck blogs.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913 et environ 1600 personnes utilisaient encore le calendrier julien, ce qui compliquait la représentation de toute date antérieure. - Maciej Piechotka


Si vous ne vous sentez pas trop mal à propos de deviner, laissez-moi vous donner une explication. Et je ne veux pas dire "quelqu'un a mis de la valeur à un non-sens", c'est évidemment toujours possible :)

Le temps Unix utilise généralement le nombre de secondes écoulé depuis 1970. Windows, quant à lui, utilise l'année 1601. Donc, si nous supposons (et c'est une grande supposition!) Que le problème est une mauvaise conversion 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é incorrectement converti en 1640 (1601 + 41). EDIT: En fait, j'ai fait une erreur dans l'année de démarrage de Windows. Il est possible que le temps de création réel ait eu lieu en 2010, ou qu’une autre erreur ait été commise (les erreurs au cas par cas 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 :)


16
2018-03-27 18:55



Donc, il se pourrait que la date ait été écrite en Unix, mais soit lue en UTC? - Fredy31
Windows utilise 1601, pas 1600. - Joey
Quelques problèmes avec cette théorie: Selon la capture d'écran, le fichier aurait été créé 11 jours après il a été utilisé pour la dernière fois. En outre, les horodatages Windows sont comptés en 100 nanosecondes, tandis que l'heure UNIX est en secondes. - Nolonar
@ Joey Ugh, mon erreur. Cela rend la crise 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 pensais. Ou, bien sûr, le fichier a été créé en 2010, pas en 2011. - Luaan
Les secondes entre l’époque Windows et la date et l’heure du fichier sont 1.266.705.294. Lorsque ajouté à l’époque Unix, cela donne 2010-02-20 23:34:54 CEST, qui était un samedi. - SQB


Comme cela a été écrit par d'autres, L'époque Windows est à 1601-01-01 00:00.

Le nombre de secondes entre cette époque et l’heure affichée, est 1.266.705.294.
Si on ajoute cela à l'époque d'Unix, on arrive à 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 quelque peu plausible. Donc, il peut avoir été un timestamp Unix interprété contre la mauvaise époque.


5
2018-03-30 07:47



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


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

le FILETIME la structure enregistre le temps sous la forme de 100 nanosecondes   intervalles 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 le 1601 est le   première année du cycle qui était actif au moment où Windows NT était   en cours de conception En d'autres termes, il a été choisi pour faire le calcul   dehors bien.

J'ai en fait le courrier électronique de Dave Cutler pour le confirmer.


2
2018-03-30 06:12