В один из дней Брюс попытался, используя стандартную функцию проводника Send To Compressed (zipped) Folder, упаковать последние исходники Process Monitor и послать мне.
Вместо обычного диалога о ходе упаковки, Проводник выдал ошибку:
Брюс был озадачен. Ошибка на первый взгляд не имела никакого смысла, так как определенно он имел права на чтение выбранных файлов, он их только что закончил редактировать, а сжатие не может затрагивать дополнительных файлов, которые могли бы быть не найдены. Он повторил операцию сжатия, но ошибка снова проявилась, правда, после другого количества файлов.
К счастью, в этот момент я появился на пороге его офиса, и он показал мне странное поведение программы. Теперь мы двое были озадачены. Пришло время провести расследование и инструментом в нем, как бы иронично это не выглядело, послужит Process Monitor.
Мы запустили программу, воспроизвели ошибку, остановили захват и начали просматривать тысячи операций в поисках ошибки. Мы увидели несколько ошибок NOT FOUND в начале лога, что обычно свидетельствует о попытке приложения проверить существование файла. На самом деле их были сотни в начале лога, все были запросы на файл, в котором будут помещены архивируемые файлы:
Это вызывало тревогу, но на самом деле не относилось к исследуемой нами проблеме, так что я отложил дело до более удобного случая.
Несколько сотен событий после мы наткнулись на ошибку SHARING VIOLATION:
Когда процесс открывает файл, он может определить, каким образом и при каких условиях он хочет разделить его с другими процессами, в ходе того как файл будет открыт. Три типа разделения - это чтение, запись, удаление, и каждый определяется своим флагом, который процесс передает CreateFile API. В операции, которая не удалась, Explorer не определил ни один из флагов, что означает его нежелание разделять файл, что видно в поле ShareMode:
Для удачного открытия файла тип разделения открывающего должен быть совместим с разделением, которое разрешается процессом, уже открывшим файл. Таким образом, объяснение этой ошибки состояло в том, что другой процесс уже открыл файл.
Вернувшись к трассировке, мы определили, что ошибке предшествовало открытие файла процессом Inort.exe. Закрытия файлов процессом не видно, так как оно случилось гораздо позднее ситуации с ошибкой. Это подтверждает, что конфликт разделения файла связан с Inort, даже несмотря на то что процесс указал возможность чтения, записи и удаления в своих условиях открытия файла.
Process Monitor закрыл дело - именно Inort держал файл открытым и вызвал ошибку разделения доступа с Explorer-ом, что и привело к появлению самой первой ошибки. Нам необходимо было определить принадлежность Inort для исправления ситуации. Process Monitor ответил и на этот вопрос:
eTrust, антивирусный сканер Computer Associates, вероятно, открыл файл для сканирования на вирусы, но его действия и операция Проводника наложились. Антивирус должен быть прозрачным для системы, так что в данном случае это полностью ошибка eTrust. Решением для Брюса стало исключение директории из списка сканируемых в реальном времени каталогов.
Когда я вернулся в офис, воспроизвести ошибку мне не удалось, я начал подозревать, что у меня другая версия антивируса, нежели чем у Брюса. Страница процессов Process Monitor действительно показала отличия. У меня была более поздняя версия - 7.01.0501.000:
Почему у нас разные версии, для меня до сих пор остается догадкой, ведь оба мы используем образы, созданные и задеплоенные администраторами Microsoft. Но зато стало ясно, что Computer Associates исправила баг в новом релизе.
Теперь настала пора вернуться к неэффективной работе процедуры сжатия в Проводнике. Я отследил компрессию одного файла и связанные с ней операции. Даже в таком простом случае Explorer открывает целевой ZIP-файл 14 раз, 12 раз до того как он на самом деле создается - все с ошибкой NOT FOUND. Кроме того, 19 раз выполняется обзор каталога. Избыточно открывается и исходный файл - 28 раз, 17 раз читаются его свойства. Похоже, Explorer предоставил eTrust массу возможностей для возникновения ошибки...
Оставалось убедиться, что за всей это вакханалией стоит именно Explorer^
Zipfldr.dll - оригинальный файл для компрессии, он светился в большинстве записей, значит именно он сам был причиной таких потерь. К тому же, учтите, что такие мусорные операции будут только возрастать с увеличением количества сжимаемых файлов! Однако совершенно очевидны пути для улучшения, и будем надеяться, что мы увидим более эффективный алгоритм в Windows 7. Собственно, уже известно, что движок архивации будет обновлен в Vista SP1.
www.xakep.ru
