如何在1641年“创建”文件？

75

几年前，我在我们的文件服务器上偶然发现了这个文件。

我不知道文件怎么能说它是1641年创建的？据我所知，pc上的时间由自1970年1月1日起的秒数来定义。如果该索引出现故障，您可以得到1969年12月31日（该索引可能显示-1），但我对此感到困惑似乎是随机的日期，甚至早于美利坚合众国的成立。

那么文件怎么会在1641年过时呢？

PS：日期是法文。Février是二月。

filesystems

— 弗雷迪31
source

29

“据我所知，个人计算机上的时间是指自1970年1月1日以来的秒数。” -即使对于存在的系统，也可以通过将该数字（称为unix时间戳）设为负数来轻松表示1970年之前的日期。例如，Unix时间-1000000000对应于1938-04-24 22:33:20。

— marcelm

1

@marcelm是的，但是由于32位整数的范围有限，可能的最小日期是1901年。

— slhck

14

@slhck：我认为marcelm假定使用64位时间戳，因为这是当前Unix / Linux文件系统，内核和用户空间软件所使用的时间戳。请参阅clock_gettime(2)手册页的的定义struct timespec，这是stat和其他系统调用使用通过用户空间和内核之间的时间戳。这是一个结构，time_t以秒为单位，long tv_nsec纳秒级。在64位系统上，两者均为64位，因此整个时间戳为128位（16字节）。（对不起，因为太详细了，我被带走了。）

— 彼得·科德斯

3

您可以很好地回答如何将1600年代的日期标记到文件上，现在该考虑一下它是如何发生的了。我将非常仔细地查看该wp文件的内容，以查看可能添加的内容，因为这可能有助于了解它的发生方式。我将查看已安装的插件，并确认没有一个插件是可疑的。我在想什么修改了该文件，并试图手动标记修改/创建的日期，以隐藏该文件已被修改，但指定了unix时间而不是Windows时间。

— Thomas Carlisle

2

国王路易十三公正党（Just Louis）展示了皇家对PHP的承诺？

— Jesse Slicer，

106

为什么可以追溯到1600年代？

Windows 不像Unix系统那样存储文件修改时间戳。根据Windows开发中心（重点是我）：

文件时间是一个64位值，代表自1601年1月1日世界协调时间（UTC）以来 100纳秒间隔的数量。当应用程序创建，访问和写入文件时，系统记录文件时间。

因此，通过在此处设置错误的值，您可以轻松获取1600年代的日期。

当然，另一个重要的问题是：该值是如何设置的？实际日期是几点？我认为您将永远无法找到答案，因为那可能只是文件系统驱动程序中的一个计算错误。另一个答案假设日期实际上是被解释为Windows时间戳的Unix时间戳，但实际上是根据不同的间隔（秒与纳秒）计算得出的。

这与2038年的问题有什么关系？

使用64位数据类型意味着Windows（通常）不受2038年的影响传统的Unix系统已遇到问题，因为Unix最初使用的是32位整数，其溢出时间比Windows的64位整数要早。拥有。（尽管Unix以秒为单位运行，而Windows以微秒/纳秒运行。）

当然，使用使用旧版本Visual Studio编译的32位程序时，Windows 仍然会受到影响。

较新的Unix操作系统已经将数据类型扩展为64位，从而避免了该问题。（实际上，由于Unix时间戳以秒为单位运行，因此从现在起，新的环绕日期将为2920亿年。）

可以设置的最大日期是多少？

对于好奇的人-这是计算方法：

的可能值的一个64位的整数数目是2 ⁶³ - 1 = 9223372036854775807。
每个刻度表示100纳秒，即0.1 µs或0.0000001 s。
最大时间范围将是9223372036854754775807⨉0.0000001 s，因此是数千亿秒。
一小时有3600秒，一天有86400秒，一年有365天，因此一年中有86400⨉365 s = 31536000 s。当然，这只是一个平均值，忽略了leap年，leap秒或将来的世界末日政权可能决定其余世人的任何日历变化。
9223372036854775807⨉0.0000001 s / 31536000 s≈29247年
@corsiKa解释了如何减去leap年：29247/365/4≈20
因此，您的最高年份为1601 + 29247 – 20 = 30828。

实际上，有些人试图设置该值，并于同年提出。

— slhck
source

7

根据记录，Unix（或至少Linux）已经解决了64位体系结构（其中time_t是64位类型）上的内核/文件系统的2038问题，因此希望应用程序使用time_t而不是仍然是32位和会截断时间戳记...无论如何，如果有人对问题的状态感到好奇，则大多数问题都可以解决，除了旧版32位。如果在2038年仍将使用32位ARM的IDK，但这将迫使至少进行ABI更改。32位x86在Unix世界中几乎消失了。只有Windows仍然使用32位代码。

— 彼得·科德斯

评论不作进一步讨论；此对话已转移至聊天。

— Journeyman Geek

1

VMS时间是一个64位值，代表自 1858年11月17日以来已过去的100纳秒间隔数。:)

— 罗恩·约翰（RonJohn）

30k年……非常低

— John Dvorak

2

@DonaldDuck blogs.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913，大约1600人仍在使用朱利安历法，使任何日期的表示都更加复杂。

— Maciej Piechotka '18

16

如果您对某些猜测不太满意，请允许我解释一下。我并不是说“有人将值设置为废话”，这显然总是可能的:)

Unix时间通常使用自1970年以来的秒数。另一方面，Windows使用1601作为起始年份。因此，如果我们假设（这是一个很大的假设！）问题是两次之间的转换错误，我们可以想象应该表示的日期实际上~~是2011年的某个时间（1970 + 41），该日期被错误地转换了至1640（1601 + 41）~~。编辑：其实，我在Windows起始年犯了一个错误。实际的创建时间可能是在2010年，或者还涉及另一个错误（在软件：D中，经常出现一个错误）。

鉴于今年恰好是与该文件相关的另一个跟踪日期，我认为这是一个很合理的解释：)

— a安
source

因此，该日期可能是用Unix编写的，但是以UTC读取的？

— Fredy31 '18

Windows使用1601，而不是1600。–

— Joey

3

该理论存在一些问题：根据屏幕截图，该文件将在上次访问后 11天创建。同样，Windows时间戳以100纳秒为单位，而UNIX时间以秒为单位。

— Nolonar

2

@Joey Ugh，我的错。这比起初看起来更不合适：)我认为相同的基本思想仍然应该起作用，但是涉及的错误可能比我想象的要多。或者，当然，该文件创建于2010年，而不是2011

— 。– Luaan

2

Windows时期与显示的文件日期/时间之间的秒数是1.266.705.294。当添加到Unix时代时，将产生2010-02-20 23:34:54 CEST，这是一个星期六。

— SQB

5

正如其他人所写，Windows时代是1601-01-01 00:00。

该时期与显示的文件时间之间的秒数为1.266.705.294。
如果将其添加到Unix时代，我们将在2010-02-20 23:34:54 CEST（星期六）到达。这距离上次访问日期大约一年，这使其看起来有些合理。因此，它可能是针对错误时期解释的Unix时间戳。

— SQB
source

奇怪的是，.NET时代是0001-01-01 00:00 UTC（比1600年早）。参见msdn.microsoft.com/en-us/library/…–

— Nayuki

2

对于这些类型的问题，照常，雷蒙德·陈（Raymond Chen）的博客对此有一个回答：“为什么Win32时代是1601年1月1日？” 从2009年3月6日开始进入：

该FILETIME结构以自1601年1月1日以来的100纳秒间隔的形式记录时间。为什么选择该日期？

公历的工作周期为400年，而1601是Windows NT设计之初活跃的周期的第一年。换句话说，它是为了使数学更好地进行选择。

实际上，我收到了Dave Cutler的电子邮件，以确认这一点。

— 埃里克·F
source