Как может файл был создан в 1641?

несколько лет назад я наткнулся на этот файл на наш сервер.

Screenshot of a file properties dialog in Microsoft Windows

и интересно, как файл может сказать, что он был создан в 1641 году? Насколько я знаю, время на ПК определяется количество секунд с 1 января 1970 года. Если этот индекс выйдет из строя, вы можете получить 31 декабря 1969 года (индекс, вероятно, говорит -1), но я озадачен этой, казалось бы, случайной датой, которая предшествует даже основанию Соединенных Штатов Америки.

Так как файл может быть датирован 1641 годом?

ЗЫ: даты по-французски. Феврье-февраль.

11
задан Fredy31
18.03.2023 15:58 Количество просмотров материала 2733
Распечатать страницу

4 ответа

почему возможна дата 1600-х годов?

Windows не хранит изменения файла, метки как делают системы Unix. Согласно Центр Разработки Windows (выделено мной):

время файла-это 64-разрядное значение, представляющее число 100 наносекунд интервалы, прошедшие с 12:00 1 января 1601 всемирное координированное время (UTC). Система записывает время создания файлов приложениями, доступ и запись в файлы.

таким образом, установив неправильное значение здесь, вы можете легко получить даты из 1600-х годов.

конечно, еще один важный вопрос: как это значение? Какова фактическая дата? Я думаю, что вы никогда не сможете узнать, как это могло бы быть просто ошибка расчета в драйвере файловой системы. другой ответ предполагает что дата на самом деле является меткой времени Unix, интерпретируемой как метка времени Windows, но они фактически рассчитано на разных интервалах (секунды против наносекунд).

как это относится к проблеме 2038 года?

использование 64-разрядного типа данных означает, что Windows (как правило) не зависит от Год 2038 Задача, что традиционные системы Unix, так как Unix изначально используется 32-разрядное целое число, которое переполняется раньше, чем 64-разрядное целое число, что Windows имеет. (Это несмотря на Unix работает на секундах и Windows, работающих на микро-и наносекунд.)

Windows по-прежнему страдает при использовании 32-битных программ, скомпилированных со старыми версиями Visual Studio, конечно.

новые операционные системы Unix уже расширен тип данных до 64 бит, что позволяет избежать эту проблему. (Фактически, поскольку временные метки Unix работают в секундах,новая дата обертывания будет 292 миллиарда лет.)

какова максимальная дата, которая может быть установить?

для любопытных - вот как это вычислить:

  • на количество возможных значений в 64-битном целочисленном are 263 – 1 = 9223372036854775807.
  • каждый тик представляет 100 наносекунд, что составляет 0,1 МКС или 0,0000001 С.
  • максимальный диапазон времени будет 9223372036854775807 ⨉ 0.0000001 s, так сотни миллиардов секунд.
  • один час 3600 секунд, один день имеет 86400 секунд, и один год имеет 365 дней, настолько там 86400 ⨉ 365 s = 31536000 s в год. Это, конечно, только среднее значение, игнорируя високосные годы, високосные секунды или любые календарные изменения, которые будущие постапокалиптические режимы могут диктовать оставшимся землянам.
  • 9223372036854775807 ⨉ 0.0000001 s / 31536000 s ≈ 29247 лет
  • @corsiKa объясняет, как мы можем убрать високосные годы: 29247 / 365 / 4 ≈ 20
  • так что ваш максимальный год 1601 + 29247 – 20 = 30828.

некоторые люди на самом деле пытался установить этот и придумали в том же году.

106
отвечен slhck 2023-03-19 23:46

Если вы не чувствуете себя слишком плохо о некоторых догадок, позвольте мне предложить объяснение. И я не имею в виду "кто-то поставил значение глупости", это, очевидно, всегда возможно:)

время Unix обычно использует количество секунд с 1970 года. Windows, с другой стороны, использует 1601 в качестве года начала. Поэтому, если мы предположим (и это большое предположение!), что проблема неправильного преобразования в два раза, можно предположить, что дата, которая должна быть представлена на самом деле где-то в 2011 (1970 + 41), который неправильно преобразован в 1640 (1601 + 41). EDIT: на самом деле, я сделал ошибку в Windows, начиная с года. Возможно, что фактическое время создания было в 2010 году, или что была другая ошибка (ошибки по одному довольно распространены в программном обеспечении :D).

учитывая, что в этом году, случается, еще одна из дат отслеживания, связанных с данным файлом, я думаю, что это довольно правдоподобное объяснение:)

16
отвечен Luaan 2023-03-20 02:03

Как писали другие,эпоха Windows в 1601-01-01 00: 00.

количество секунд между этой эпохой и filetime и отображается is 1.266.705.294.

Если мы добавим это к эпохе Unix, то получим 2010-02-20 23:34: 54 CEST, суббота. Это примерно за год до последней даты доступа, что делает ее несколько правдоподобной. Так что это может быть метка времени Unix, толковать неправильно эпоха.

5
отвечен SQB 2023-03-20 04:20

как обычно для таких вопросов, блог Раймонда Чена имеет ответ относительно этого из "Почему Win32 epoch январь 1, 1601?"запись от 6 марта 2009 года,:

FILETIME структура записывает время в виде 100 наносекунд интервалов с 1 января 1601 года. Почему была выбрана эта дата?

Григорианский календарь работает по 400-летнему циклу, а 1601 год является первый год цикла, который был активен в то время Windows NT был разрабатывается. Другими словами, он был выбран, чтобы сделать математику очень красиво.

У меня есть письмо от Дейва Катлера, подтверждающее это.

2
отвечен ErikF 2023-03-20 06:37

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх