Làm thế nào một tập tin có thể được 'tạo' vào năm 1641?

75

Vài năm trước, tôi tình cờ thấy tập tin này trên máy chủ tập tin của chúng tôi.

Và tôi tự hỏi làm thế nào một tập tin có thể nói nó được tạo ra vào năm 1641? Theo như tôi biết, thời gian trên máy tính được xác định bằng số giây kể từ ngày 1 tháng 1 năm 1970. Nếu chỉ số đó bị trục trặc, bạn có thể nhận được ngày 31 tháng 12 năm 1969 (chỉ số có thể nói là -1) nhưng tôi bị vấp ngã ở đây ngày dường như ngẫu nhiên, mà ngay cả trước khi thành lập Hợp chủng quốc Hoa Kỳ.

Vì vậy, làm thế nào một tập tin có thể được niên đại vào năm 1641?

PS: Ngày tháng bằng tiếng Pháp. Février là tháng hai.

filesystems

— Fredy31
nguồn

29

"Theo như tôi biết, thời gian trên pc được xác định bằng số giây kể từ ngày 1 tháng 1 năm 1970." - Ngay cả đối với các hệ thống có nó, ngày trước năm 1970 được thể hiện dễ dàng bằng cách làm cho số đó (được gọi là dấu thời gian unix ) âm. Ví dụ: thời gian unix -1000000000 tương ứng với 1938-04-24 22:33:20.

— marcelm

1

@marcelm Có, nhưng ngày tối thiểu có thể là vào năm 1901 do phạm vi giới hạn của số nguyên 32 bit.

— slhck

14

@slhck: Tôi nghĩ rằng marcelm đã giả sử dấu thời gian 64 bit, bởi vì đó là những gì hệ thống tập tin Unix / Linux hiện tại, hạt nhân và phần mềm không gian người dùng sử dụng. Xem clock_gettime(2)trang hướng dẫn để biết định nghĩa struct timespec, đó là những gì statvà các lệnh gọi hệ thống khác sử dụng để vượt qua dấu thời gian giữa không gian người dùng và kernel. Đó là một cấu trúc với một time_tgiây và một long tv_nsecnano giây. Trên các hệ thống 64 bit, cả hai đều là 64 bit, vì vậy toàn bộ dấu thời gian là 128 bit (16 byte). (Xin lỗi vì quá nhiều chi tiết, tôi đã mang đi.)

— Peter Cordes

3

Bạn đã có một câu trả lời tốt về cách một ngày trong những năm 1600 có thể được đóng dấu vào tập tin, bây giờ là lúc để suy nghĩ về cách nó đã xảy ra. Tôi sẽ xem xét nội dung của tệp wp đó thật kỹ để xem những gì có thể đã được thêm vào, vì điều đó có thể làm sáng tỏ về cách nó xảy ra. Tôi sẽ xem xét các plugin đã cài đặt và xác nhận không có plugin nào mờ ám. Tôi đang suy nghĩ điều gì đó đã sửa đổi tệp đó và cố gắng đóng dấu ngày đã sửa đổi / tạo ra để ẩn rằng tệp đã được sửa đổi nhưng chỉ định thời gian unix thay vì thời gian của windows.

— Thomas Carlisle

2

Vua Louis XIII chỉ là thể hiện cam kết của dòng dõi hoàng gia với PHP?

— Jesse Choper

106

Tại sao một ngày từ những năm 1600 có thể?

Windows không lưu trữ dấu thời gian sửa đổi tệp như các hệ thống Unix làm . Theo Trung tâm Dev Windows (nhấn mạnh của tôi):

Thời gian tệp là một giá trị 64 bit đại diện cho số lượng khoảng thời gian 100 nano giây đã trôi qua kể từ 12:00 sáng ngày 1 tháng 1 năm 1601 Giờ quốc tế phối hợp (UTC). Hệ thống ghi lại thời gian tập tin khi các ứng dụng tạo, truy cập và ghi vào tập tin.

Vì vậy, bằng cách đặt giá trị sai ở đây, bạn có thể dễ dàng nhận được ngày từ 1600s.

Tất nhiên, một câu hỏi quan trọng khác là: giá trị này được đặt như thế nào? Ngày thực tế là gì? Tôi nghĩ rằng bạn sẽ không bao giờ có thể tìm ra, vì đó có thể chỉ đơn giản là một lỗi tính toán trong trình điều khiển hệ thống tệp. Một câu trả lời khác đưa ra giả thuyết rằng ngày thực sự là dấu thời gian Unix được hiểu là dấu thời gian của Windows, nhưng chúng thực sự được tính trên các khoảng thời gian khác nhau (giây so với nano giây).

Làm thế nào điều này liên quan đến vấn đề năm 2038?

Việc sử dụng loại dữ liệu 64 bit có nghĩa là Windows (nói chung) không bị ảnh hưởng bởi Vấn đề Năm 2038 mà các hệ thống Unix truyền thống gặp phải, do Unix ban đầu sử dụng số nguyên 32 bit, vượt quá số nguyên 64 bit mà Windows có. (Điều này bất chấp Unix hoạt động trên giây và Windows hoạt động trên micro / nano giây.)

Windows vẫn bị ảnh hưởng khi sử dụng các chương trình 32 bit được biên dịch với các phiên bản cũ của Visual Studio.

Các hệ điều hành Unix mới hơn đã mở rộng kiểu dữ liệu lên 64 bit, do đó tránh được sự cố. (Trên thực tế, vì các dấu thời gian Unix hoạt động trong vài giây, ngày kết thúc mới sẽ là 292 tỷ năm kể từ bây giờ.)

Ngày tối đa có thể được thiết lập là gì?

Đối với những người tò mò - đây là cách tính toán:

Số lượng giá trị có thể có trong số nguyên 64 bit là 2 ⁶³ - 1 = 9223372036854775807 .
Mỗi đánh dấu đại diện cho 100 nano giây, là 0,1 Đài hoặc 0,0000001 giây.
Phạm vi thời gian tối đa sẽ là 9223372036854775807 0,0000001 s , vì vậy hàng trăm tỷ giây.
Một giờ có 3600 giây, một ngày có 86400 giây và một năm có 365 ngày, do đó, có 86400 ⨉ 365 s = 31536000 s trong một năm. Tất nhiên, đây chỉ là một mức trung bình, bỏ qua các năm nhuận, giây nhuận hoặc bất kỳ thay đổi lịch nào mà chế độ hậu tận thế trong tương lai có thể ra lệnh cho các trái đất còn lại.
9223372036854775807 0,0000001 s / 31536000 s ≈ 29247 năm
@corsiKagiải thích cách chúng ta có thể trừ đi các năm nhuận: 29247/365/4 20
Vậy năm tối đa của bạn là 1601 + 29247 - 20 = 30828 .

Một số người thực sự đã cố gắng thiết lập điều này và đưa ra cùng một năm.

— slhck
nguồn

7

Đối với bản ghi, Unix (hoặc ít nhất là Linux) đã giải quyết vấn đề 2038 cho kernel / hệ thống tập tin trên các kiến trúc 64 bit trong đó time_tlà loại 64 bit, vì vậy, hy vọng các ứng dụng sử dụng time_tthay vì loại số nguyên vẫn là 32 bit và sẽ cắt bớt dấu thời gian ... Dù sao đi nữa, trong trường hợp bất kỳ ai cũng tò mò về tình trạng của vấn đề, nó chủ yếu được giải quyết ngoại trừ di sản 32-bit. IDK nếu ARM 32 bit vẫn có liên quan vào năm 2038, nhưng điều này sẽ buộc ít nhất phải thay đổi ABI. 32-bit x86 đã xuất hiện khá nhiều trong thế giới Unix; Chỉ có Windows nơi mã 32 bit vẫn phổ biến.

— Peter Cordes

Bình luận không dành cho thảo luận mở rộng; cuộc trò chuyện này đã được chuyển sang trò chuyện .

— Journeyman Geek

1

Thời gian VMS là " giá trị 64 bit đại diện cho số lượng khoảng thời gian 100 nano giây đã trôi qua kể từ " ngày 17 tháng 11 năm 1858. :)

— RonJohn

Năm 30k là ... thấp đáng ngạc nhiên

— John Dvorak

2

@DonaldDuck blogs.msdn.microsoft.com/oldnewthing/20090306-00/?p=18913 và khoảng 1600 người bị vẫn còn sử dụng Julian đại diện làm lịch của ngày nào trước đó phức tạp hơn.

— Maciej Piechotka

16

Nếu bạn không cảm thấy quá tệ về một số phỏng đoán, hãy để tôi đưa ra một lời giải thích. Và tôi không có nghĩa là "ai đó đặt giá trị thành vô nghĩa", điều đó rõ ràng là luôn luôn có thể :)

Thời gian Unix thường sử dụng số giây kể từ năm 1970. Mặt khác, Windows sử dụng 1601 làm năm bắt đầu. Vì vậy, nếu chúng ta giả định (và đó là một giả định lớn!) Rằng vấn đề là chuyển đổi sai giữa hai lần, chúng ta có thể tưởng tượng rằng ngày được cho là đại diện thực sự ~~vào khoảng năm 2011 (1970 + 41), đã chuyển đổi không chính xác đến 1640 (1601 + 41)~~ . EDIT: Thật ra, tôi đã mắc một lỗi trong năm bắt đầu của Windows. Có thể thời gian tạo thực tế là vào năm 2010 hoặc có một lỗi khác liên quan (lỗi do một lỗi khá phổ biến trong phần mềm: D).

Cho rằng năm nay tình cờ là một ngày theo dõi liên quan đến tệp được đề cập, tôi nghĩ đó là một lời giải thích khá hợp lý :)

— Luaan
nguồn

Vì vậy, nó có thể là ngày được viết bằng Unix, nhưng được đọc bằng UTC?

— Fredy31

Windows sử dụng 1601, không phải 1600.

— Joey

3

Một vài vấn đề với lý thuyết đó: Theo ảnh chụp màn hình, tệp sẽ được tạo sau 11 ngày kể từ lần truy cập cuối cùng. Ngoài ra, dấu thời gian của Windows được tính bằng 100 nano giây, trong khi thời gian UNIX tính bằng giây.

— Nolonar

2

@Joey Ugh, lỗi của tôi. Điều đó làm cho sự phù hợp trở nên tồi tệ hơn nhiều so với cái nhìn đầu tiên :) Tôi nghĩ rằng ý tưởng cơ bản tương tự vẫn sẽ hoạt động, nhưng có lẽ có nhiều lỗi liên quan hơn tôi nghĩ. Hoặc, tất nhiên, tệp được tạo vào năm 2010, không phải năm 2011

— Luaan

2

Giây giữa Windows epoch và ngày / giờ tệp hiển thị là 1.266.705.294 . Khi được thêm vào Unix epoch, điều này mang lại 2010 / 02-20 23:34:54 CEST , đó là một ngày thứ bảy.

— SQB

5

Như đã được viết bởi những người khác, kỷ nguyên Windows là vào lúc 1601-01-01 00:00 .

Số giây giữa kỷ nguyên đó và thời gian hiển thị, là 1.266.705.294 .
Nếu chúng ta thêm nó vào kỷ nguyên Unix, chúng ta sẽ đến 2010 / 02-20 23:34:54 CEST , thứ bảy. Đây là khoảng một năm trước ngày truy cập cuối cùng, điều này làm cho nó có phần hợp lý. Vì vậy, nó có thể là một dấu thời gian Unix được giải thích chống lại kỷ nguyên sai.

— SQB
nguồn

Thật kỳ lạ, .NET epoch là 0001-01-01 00:00 UTC (tức là 1600 năm trước). Xem msdn.microsoft.com/en-us/l Library / từ

— Nayuki

2

Như thường lệ đối với các loại câu hỏi này, blog của Raymond Chen có câu trả lời liên quan đến câu hỏi này từ "Tại sao kỷ nguyên Win32 ngày 1 tháng 1 năm 1601?" nhập cảnh từ ngày 6 tháng 3 năm 2009:

Các FILETIMEcấu trúc ghi lại thời gian theo hình thức khoảng 100 nano giây kể từ tháng 1, 1601. Tại sao ngày đó chọn?

Lịch Gregorian hoạt động theo chu kỳ 400 năm và 1601 là năm đầu tiên của chu kỳ hoạt động tại thời điểm Windows NT được thiết kế. Nói cách khác, nó đã được chọn để làm cho toán học trở nên độc đáo.

Tôi thực sự có email từ Dave Cutler xác nhận điều này.

— ErikF
nguồn