В один из дней Брюс попытался, используя стандартную функцию проводника
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.

Оставить мнение

Check Also

Страдания с ReactOS. Почему в заменителе Windows работают трояны, но не работает Word

Сегодня в нашей кунсткамере демонстрируется необычайный организм — двадцатилетний зародыш …