題 如何在1641年“創建”文件?


幾年前,我在我們的文件服務器上偶然發現了這個文件。

Screenshot of a file properties dialog in Microsoft Windows

我想知道一個文件怎麼說它是在1641年創建的?據我所知,pc上的時間是由1970年1月1日以來的秒數定義的。如果該指數出現故障,你可以得到1969年12月31日(該指數可能表示為-1)但我很難過看似隨機的日期,甚至早於美利堅合眾國的成立。

那麼文件如何在1641年過時呢?

PS:日期是法語。 Février是二月。


74
2018-03-27 14:33


起源


“據我所知,個人電腦上的時間是自1970年1月1日以來的秒數。”  - 即使對於那樣的系統,1970年之前的日期很容易用這個數字來表示(稱為a unix時間戳)否定的。例如,unix時間-1000000000對應於1938-04-24 22:33:20。 - marcelm
@marcelm是的,但由於32位整數的範圍有限,因此1901年的最小可能日期。 - slhck
@slhck:我認為marcelm正在假設64位時間戳,因為這是當前Unix / Linux文件系統,內核和用戶空間軟件所使用的。見 clock_gettime(2) 手冊頁 的定義 struct timespec,這是什麼 stat和其他系統調用用於傳遞用戶空間和內核之間的時間戳。這是一個結構 time_t 在幾秒鐘內,和 long tv_nsec 納秒。在64位系統上,兩者都是64位,因此整個時間戳是128位(16字節)。 (對不起,太多細節,我被帶走了。) - Peter Cordes
您可以很好地回答如何將17世紀的日期標記到文件中,現在是時候思考它是如何發生的了。我會非常仔細地查看該wp文件的內容以查看可能添加的內容,因為這可能會揭示它是如何發生的。我會看看已安裝的插件,並驗證沒有陰影。我正在考慮修改該文件並試圖手動標記修改/創建日期以隱藏文件被修改但指定了unix時間而不是windows時間。 - Thomas Carlisle
國王路易十三Just正在展示皇家系列對PHP的承諾? - Jesse Slicer


答案:


為什麼17世紀的日期可能?

Windows不存儲文件修改時間戳 像Unix系統那樣。根據 Windows開發人員中心 (強調我的):

文件時間是64位值,表示100納秒的數量 自上午12:00起經過的時間間隔1601年1月1日 協調世界時(UTC)。應用程序創建,訪問和寫入文件時,系統會記錄文件時間。

因此,通過在此處設置錯誤的值,您可以輕鬆地從17世紀開始獲取日期。

當然,另一個重要的問題是:這個價值是如何設定的?什麼是實際日期?我想你永遠無法找到,因為這可能只是文件系統驅動程序中的計算錯誤。 另一個答案是假設 該日期實際上是解釋為Windows時間戳的Unix時間戳,但它們實際上是按不同的時間間隔(秒與納秒)計算的。

這與2038年問題有什麼關係?

使用64位數據類型意味著Windows(通常)不受此影響 2038年問題 傳統的Unix系統,因為Unix最初使用的是32位整數,它比Windows的64位整數溢出得更快。 (儘管Unix在幾秒鐘內運行,Windows在微秒/納秒運行。)

視窗 仍然受到影響 當然,當使用用舊版本的Visual Studio編譯的32位程序時。

較新的Unix操作系統 已經擴大了 數據類型為64位,從而避免了這個問題。 (事實上,由於Unix時間戳在幾秒鐘內運行,因此新的環繞日期將從現在開始為2920億年。)

可以設置的最長日期是多少?

對於好奇的 - 這是如何計算:

  • 64位整數中可能的值的數量 是 263  - 1 = 9223372036854775807
  • 每個刻度表示100納秒,即0.1μs或0.0000001 s。
  • 最大時間範圍是 9223372036854775807⨉0.0000001s,數千億秒。
  • 一小時有3600秒,一天有86400秒,一年有365天,所以有 86400⨉365 s = 31536000 s 在一年以內。當然,這只是一個平均值,忽略了閏年,閏秒,或未來後世界末日政權可能對其餘地球人所要求的任何日曆變化。
  • 9223372036854775807⨉0.0000001s / 31536000s≈29247年
  • @corsiKa 解釋了我們如何減去閏年: 29247/365/4≈20
  • 所以你的最大年份是 1601 + 29247 - 20 = 30828

有些人有 實際上試圖設置這個 並在同一年提出。


106
2018-03-27 14:41



為了記錄,Unix(或至少Linux)已經解決了64位架構上的內核/文件系統的2038問題 time_t 是64位類型,所以希望應用程序使用 time_t 而不是仍然是32位的整數類型並且會截斷時間戳...無論如何,如果有人對問題的狀態感到好奇,除了傳統的32位之外,它主要解決了。 IDK如果32位ARM在2038年仍然具有相關性,但這將至少迫使ABI發生變化。在Unix世界中,32位x86幾乎消失了;它只是Windows,其中32位代碼仍然很常見。 - Peter Cordes
評論不適用於擴展討論;這次談話已經開始了 轉移到聊天。 - Journeyman Geek♦
VMS時間是“一個64位值,表示自此以來經過的100納秒間隔的數量“1858年11月17日。:) - RonJohn
30k年......令人驚訝地低 - John Dvorak
@DonaldDuck blogs.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913 大約1600人仍然使用朱利安日曆來表示任何日期之前更複雜。 - Maciej Piechotka


如果你對某些猜測感覺不太好,請允許我提供一個解釋。而且我並不是說“有人把價值定為廢話”,這顯然總是可能的:)

Unix時間通常使用自1970年以來的秒數。另一方面,Windows使用1601作為起始年份。因此,如果我們假設(並且這是一個很大的假設!)問題是兩次之間的錯誤轉換,我們可以想像應該表示的日期實際上是 在2011年的某個時間(1970 + 41),錯誤地轉換為1640(1601 + 41)。編輯:實際上,我在Windows開始的一年裡犯了一個錯誤。實際創建時間可能是在2010年,或者涉及到另一個錯誤(逐個錯誤在軟件中很常見:D)。

鑑於今年恰好是與該文件相關的另一個跟踪日期,我認為這是一個非常合理的解釋:)


16
2018-03-27 18:55



所以可能是日期是用Unix編寫的,但是用UTC讀取? - Fredy31
Windows使用1601而不是1600。 - Joey
該理論存在一些問題:根據屏幕截圖,該文件將在11天內創建 後 它是最後一次訪問。此外,Windows時間戳計為100納秒,而UNIX時間以秒為單位。 - Nolonar
@Joey呃,我的錯。這使得合適比乍一看更糟糕:)我認為同樣的基本想法應該仍然有效,但可能涉及的錯誤比我想像的要多。或者,當然,該文件是在2010年創建的,而不是2011年。 - Luaan
Windows紀元和顯示的文件日期/時間之間的秒數是 1.266.705.294。當添加到Unix紀元時,這會產生 2010-02-20 23:34:54 CEST這是星期六。 - SQB


正如其他人寫的那樣, Windows紀元是1601-01-01 00:00

該紀元與顯示的文件時間之間的秒數, 是1.266.705.294
如果我們將它添加到Unix時代,我們就會到達 2010-02-20 23:34:54 CEST星期六這是在最後一次訪問日期之前大約一年,這使它有點合理。因此它可能是針對錯誤時期解釋的Unix時間戳。


5
2018-03-30 07:47



奇怪的是,.NET時代是0001-01-01 00:00 UTC(早在1600年前)。看到 msdn.microsoft.com/en-us/library/... - Nayuki


像往常一樣,Raymond Chen的博客對此有一個答案 來自“為什麼是Win1時代1601年1月1日?”從2009年3月6日開始:

FILETIME 結構以100納秒的形式記錄時間   自1601年1月1日起的時間間隔。為什麼選擇該日期?

公曆運行400年,1601年   在Windows NT時活動的周期的第一年   正在設計中。換句話說,它被選中來使數學成為現實   出來很好。

我實際上有Dave Cutler的電子郵件確認了這一點。


2
2018-03-30 06:12