Closed VictorVG closed 9 years ago
Добрался до машины №2 где этот сбой имеет место, посмотрел по FTP - явление наблюдается только на файлах дата создания/модификации которых новее чем 20.10.2014 что позволяет выдвинуть гипотезу о его природе - сбой как-то связан с KB2998527 Обновление 2014 часового пояса для России
но что важно он проявляется только для старше чем b341 - на более старых его не видели. Результаты проявления этого странного эффекта мы видим на хинтах cкриншотов:
b4165 + NetBox v2 1 40 349
FTP RarLABS:
b4169 + NetBox v2 1 40 350 - скриншоты с разных серверов:
FTP RarLABS:
FTP Libre Office:
Проверил на билде 351 - намного лучше, да и виновник ошибки явно локализовался - WinSCP неправильно время считает. На ftp.rarlabs.com/rar/ теперь порядок, что не скажешь о заркалах Libre Office (v4.3.3 вышла 30.10.2014, WinSCP говорит мол 02.03.2015 примерно + 4 месяца):
И на серверах FreeBSD ORG - там она вообще не понятно что считает:
а смотрим в FileZilla Client 3.9.0.6 и видим правильные даты (ну как минмум правдоподобные):
Посмотрел тот же сервер ftp5.gwdg.de/pub/tdf/libreoffice/ (анонимный вход, пассивный режим FTP) в связке Far b4169 r12624 +NetBox v2.1.40.352 так у меня на подозрении WinSCP - именно там происходит ошибка даты, и вот что видим (важное я отчеркнул):
что инересно если исразу после подключения к серверу дату создания каталога плагин показывает как 30.12.99 00:00, то по мере перемещения по дереву выводимая дата для этого же каталога и файлов в нём произвольно меняется. Для сравнения можем посмотреть те же объёкты ФС в MultiCommander 4.6.2.1804:
что облегчит нам ориентацию во времени. Я почему на WinSCP грешу - как только в ней правится одна её ошибка так сразу на FTP пара новых вылезает...
Собрал и проверил ь353 и вижу - время создания каталогов скакать перестало, файлов пока считается неправильно (сервер тот же самый - ftp5.gwdg.de/pub/tdf/libreoffice/ ):
судя по всему ошибку надо ожидать в src/core/Common.cpp::1437 - src/core/Common.cpp ::1443 поскольку как я понимаю этот фрагмент у нас отвечает за расчёт даты. Возможно что ему на вход приходит мусор, но результатом становится временное смещение примерно в +150 суток относительно реальной даты создания файла.
Я проверил гипотезу о возможной ошибке профиля просто удалив его и перенастроив всё заново - не подтвердилась, даты создания файлов в каталогах на данном FTP выводимые плагином опережают реальные на те же +150 суток...
Я посмотрел данные предоставляенмые всеми проверенными серверами:
ftp.rarlabs.com - уже не проявляется ftp.freebsd.org - проявляется ftp5.gwdg.de - проявляется
Remote system = UNIX Type: L8 Session protocol = FTP Compression = No
Can change permissions = Yes Can change owner/group = No Can execute arbitrary command = Protocol commands only Can create symlink/hardlink = No/No Can lookup user groups = No Can duplicate remote files = No Can check available space = No Can calculate file checksum = No Native text (ASCII) mode transfers = No
Additional protocol information The server supports these FTP additional features: EPRT EPSV MDTM PASV REST STREAM SIZE TVFS UTF8
и случайно обнаружил ещё один сервер где наблюдается данное явление:
ftp://ftp.omnilan.de/pub/Applications/Windows/.Favourites/Java-RunTimeEnvironment/ - проявляется
Remote system = UNIX Type: L8 Version: BSD-199506 Session protocol = FTP Compression = No
Can change permissions = Yes Can change owner/group = No Can execute arbitrary command = Protocol commands only Can create symlink/hardlink = No/No Can lookup user groups = No Can duplicate remote files = No Can check available space = No Can calculate file checksum = No Native text (ASCII) mode transfers = No
Additional protocol information The server supports these FTP additional features: MDTM REST STREAM SIZE на всех серверах где данный эффект наблюдается время создания файлов относительно того, что сообщает сервер сдвинуто примерно на +150 суток. Так что можно считать что где-то сидит опечатка проявляющаяся в виде поправки при подсчёте времени....
Коммит 4c61bdf0ae на RarLABS опять стал чудить, причём ещё больше - смотрим время записи у wrar520b3.exe (тестировал на Far b4173 ибо ь4174 вышел неудачным - слетели настройки плагинов и цвета, ну и макросы до кучи легли):
в v2.1.40.354 было верным - 07.11.2014 23:21 - коммит 4c61bdf0ae выводит время 12.03.2015 18:21:00 т.е. при ремонте Mantis #0002860 и Mantis #0002859 доломали считывание времени. :-)
Ещё раз пробежался по цепочке изменений: b341 - явления нет, b343 обновилась WinSCP до v5.6.2 и появилось, b347, b350 - b354-4c61bdf0ae есть, воспроизводимость 100%, баг в WinSCP 5.6.2. Хоть откатывай до b341 ибо баг с подсчётом времени гарантирует случайную перезапись данных их более старой репликой т.е. потерю данных ...
Баг пришлось переименовать чтобы понятно было (ночью уже восстанавливал данные с UNIX FTP на который ориентируясь на ошибочное время охранник случайно слил старые записи камер поверх вчерашних. Воплей там хватило.:) До сих пор голова от них болит.:))
Собрал b356 - ошибка с датой устранена. Миша огромное спасибо! Этот помотавший нам нервы инц закрываю - достал основательно, глаза бы мои его не видели. :)
Получил письмо от приятеля на руборде о странном переносе файлов на ftp.rarlabs.com в будущее - не на час как у меня было, а в 2015-й год:
в то же время у меня на одной машине всё в порядке, на другой со временем та же петрушка. Обратил внимание что она проявилась в ь343 пошла далее, но у меня на рабочей машине стоит ь349 и ничего этого я не вижу:
Интересное явление. Понять бы его природу. Я на той машине специально ставил Oracle tzupdater-1_4_8-2014h.zip - думал М$ чего по свой привычке начудила, и приятелю его же переслал - он поставил, ребутнул ОС, проверил - ничего не изменилось. Похоже ошибка у нас бегает...
И заодно вопрос - куда копать с Error 217? Откуда вот эта пакость лезет:
О ней известно что с высокой вероятностью её источником является Дельфи - AV возникает при закрытии модулей когда обработчики прерываний завершаются раньше срока... Пока не могу сообразить куда копать, да и вылезает она когда ей вздумается...