Проблема следующая:
в ходе эксперементов было выявлено, что на разделах NTFS эта функция дает разницу в час, если файл был записан летом, а просмотр проводится зимой (или наоборот).
Свойства файлов Windows и TotalCommander не учитывают эту особенность и наблюдается интересная вещь:
Ведь если мы создали файл 2.12 в 23.45, то и при просмотре летом информаци об этом файле (переведем время на июнь хотя бы) дата его создания все равно должна быть 2.12 в 23.45, а свойства файлов Windows отображают 03.12 в 00.45 !!!!!
Свойтсва файлов Windows меня мало интересуют , но Гхислеру надо наверное об этом сообщить..
В MSDN написано про подобное поведение и предложена альтернатива - группа функций, приводящая к корректным результатам:
prog_san
Проблема давно известна, в том числе и Гислеру. О чём в справке Тотала совершенно ясно написано при рассмотрении указанной далее опции.
Про группу функций - это всё замечательно, но что, собственно, конкретно предлагается делать по этому поводу в Тотале? Простыми русскими словами?
olega писал(а):Настройки->Основные операции->Коррекция времени на NTFS->Игнорировать разницу в 1 ч
Это не то?
То, да не совсем. Указанная опция позволяет игнорировать возникшую разницу в один час в функциях сравнения и синхронизации. И всё. Хотя и это очень полезно.
Даже самая богатая фантазия
Не представит себе наши безобразия.
olega писал(а):Настройки->Основные операции->Коррекция времени на NTFS->Игнорировать разницу в 1 ч
Это не то?
Это хорошо, что он учел этот момент при сравнении файлов. Но я не про это..
Avada писал(а):
Проблема давно известна, в том числе и Гислеру. О чём в справке Тотала совершенно ясно написано при рассмотрении указанной далее опции.
Про группу функций - это всё замечательно, но что, собственно, конкретно предлагается делать по этому поводу в Тотале? Простыми русскими словами?
А почему же он не использует эту связку для вычисления времен файлов? Ее использование устранит неправильное отображение времени.
Может быть, чтобы избежать расхождения показаний с Windows?
По-моему если файл создан 02.12 в 23.45, то и летом дата его создания должна отображаться как 02.12 в 23.45, а не 03.12 в 00.45.
prog_san
Я не программист, в тонкостях применения вышеупомянутых функций не разбираюсь и сужу об этом исключительно с позиции честного битого юзера, хотя и с изрядным стажем. Возможно, специалисты меня поправят.
Так вот. Можно считать такое отображение времени правильным или неправильным, но мне не известен НИ ОДИН файл-менеджер, где синхронизация "на лету" изменёного ранее в NTFS времени была бы осуществлена и где такая задача хотя бы серьёзно ставилась. Что предлагается-то? При открытии каждого каталога быстренько пересканировать время файлов и, грубо говоря, для созданных в зимний период час минусовать летом, а для созданных в летний - плюсовать зимой? (На самом деле там всё ещё сложнее, я сознательно упрощаю.) Причём реально ничего не менять, а только отображать таким образом в данной конкретной программе? Кому из разработчиков такие подвиги нужны? Да и в расхождении показаний с Windows счастья будет мало.
Даже самая богатая фантазия
Не представит себе наши безобразия.
Avada писал(а):
Так вот. Можно считать такое отображение времени правильным или неправильным, но мне не известен НИ ОДИН файл-менеджер, где синхронизация "на лету" изменёного ранее в NTFS времени была бы осуществлена и где такая задача хотя бы серьёзно ставилась. Что предлагается-то?
Я не про синхронизацию.. Пусть она работает, как работала. Там все и так замечательно. Я про отображение времени в списке файлов на панелях... Если файл был изменен в определенное время - это время и дожно отображаться, безовсяких часовых сдвигов в зависимости от сезона... Не так ли?
Avada писал(а):
Кому из разработчиков такие подвиги нужны? Да и в расхождении показаний с Windows счастья будет мало.
Файловая система фиксирует время корректно - проблема только в правильном отображении ее пользователю. И если Windows это выполняет некорректно, это еще не означает того, что TotalCommander должен уподобляться ей.
Повторюсь - я за то, что если файл был создан(изменен, к нему происходил доступ) в конкретное время, это время и ДОЛЖНО отображаться.
Решение же я предлагал выше. Как написано в MSDN. Связка трех функций, вместо использования FileTimeToLocalFileTime
Да, спасибо, посмотрел. Но, как уже было сказано, в силу ограниченой компетентности в данном вопросе конкретика применения всех этих замечательных механизмов для меня не вполне понятна. Равно как и то, почему, если это всё так просто и очевидно, то уже не реализовано кем-то на уровне файл-менеджеров, которых сейчас как собак нерезаных.
Поскольку по основному вопросу я больше ничего дельного сказать не в состоянии, могу лишь порекомендовать выйти на официальный сайт TC и попытаться донести эту идею до Гислера напрямую. Со всеми резонами и отсылками. В чём и желаю всяческих успехов.
Даже самая богатая фантазия
Не представит себе наши безобразия.
, но Гхислеру надо наверное об этом сообщить.. 
