“Во время разговора оба держали руки на рукоятке, и поистине остается загадкой, как случилось, что рукоять оттянулась назад и поезд остановился. Оба никак не могли прийти к соглашению, кто, собственно, подал сигнал тревоги.”
Ярослав Гашек. “Похождения бравого солдата Швейка”

В любой многозадачной/многопользовательской системе необходима специальная служба для отслеживания одновременного доступа к одному файлу со стороны нескольких программ и разрешения возникающих конфликтов. Она страхует обратившуюся к файлу программу от искажений данных. Windows, конечно, не исключение. Поэтому, пытаясь открыть любой файл, программа информирует операционную систему (ОС) о режиме работы с ним (например, чтение или чтение-запись) и об ограничениях на доступ для других программ (например, полный запрет или разрешение чтения). Программа или процесс могут освободить файл в ходе работы. Завершаясь, они должны это сделать в любом случае.

Это в теории. На практике вмешиваются вездесущие ошибки. Сравнительно простые программы сюрпризов, обычно, не преподносят. Даже аварийное завершение задачи («программа выполнила недопустимую операцию») для Windows не проблема, поскольку существует список открытых файлов с указанием «держателя». В среде Win9x его, как и массу другой системной информации, можно получить с помощью утилиты TaskInfo.

От монстров, в ряду которых неоспоримый лидер MS Office, можно ожидать чего угодно. Весьма распространена ситуация, когда после краха Word'а среди активных процессов остается какой-то «невидимый» его кусок. За ним могут числится не только временные файлы, но и шаблоны и документы. Повторный запуск Word на этот огрызок не действует, если не считать учащения конфликтов, ошибок и новых крахов с тем же исходом. Количество расплодившихся «невидимок» ограничивается только объемом оперативной памяти и стоицизмом пользователя, не желающего перезагружать систему. На самом деле проблема решается удалением лишних процессов Winword в окне стандартного менеджера задач (Ctrl+Alt+Del — Завершить задачу) или того же TaskInfo (File —>Terminate Process).

Но существуют и более экзотические ситуации.Вот однажды без всякой видимой причины компьютер в ответ на попытку каких-либо манипуляций с файлами вдруг начал сообщать « Занято!» (рис. 1).

Рис. 1. Нет доступа?!

Сообщение не слишком информативное. Кто держит файл? При чем тут переполнение диска? Неужели ОС не может отличить защиту по записи от занятости другим приложением? Ведь всю эту информацию Windows знает. Видимо, заботясь о пользователях, не хочет их чересчур огорчать. Вот только, когда отчаявшийся разобраться юзер задаст «гуру» вопрос о причинах ошибки, то скорее всего получит стандартный ответ из упрощенного лексикона русского языка (см. на ближайшем заборе).

Ладно, хоть и без усов, но разберемся сами. Тип файла значение не имел, как и последовательность работавших с ним программ. Перезагрузка компьютера, конечно разрешала проблему, только ошибка-то оставалась на месте и вскоре вылезала опять. Методом тыка удалось установить, что блокировка происходит при определении свойств файла (Файл (или правая кнопка мыши) —> Свойства), а утилита TaskInfo показала (рис. 2), что блокируемый числится за Проводником (Explorer).

Рис. 2. Виноват ли Проводник?

Вот те раз. Операции «Свойства» и «Удаление» выполняет Проводник. Получается он заблокировал файл от самого себя? Левая рука не знает, что делает правая. Очевидно, что сам Explorer не виноват, поскольку на чистой системе такого не бывает. Значит эффект появляется вследствие установки какой-то программы, неуклюже расширяющей функции оболочки. Ошибка состоит в том, что дополняющий код, выполнив свою задачу, не закрывает файл. Система же разделения доступа продолжает удерживать его за Проводником, который по замыслу авторов должен работать вечно.

Значит, чтобы найти ошибку, необходим протокол файловых операций во время выполнения функции « Свойства». Такую информацию предоставит утилита File Monitor. (Как и другие программы Марка Руссиновича ее нужно запускать из папки размещения либо проследить, чтобы в ярлыке программы она была указана рабочим каталогом. Иначе монитор не найдет свои VxD и SYS драйверы).

В этот раз задача решилась быстро (рис. 3). В ловушку попался ZipMagic 2000 v. 3.

Рис. 3. По-видимому, проблему создают rar-модули из ZipMagic.

Программа эта предназначена для представления архивов (zip, gz, rar, lzh и т.д.) в виде папок Windows. Она также встраивает свои модули в оболочку таким образом, чтобы при определении свойств архива можно было сразу получить полный доступ к его содержимому (рис. 4).

Рис. 4. «Свойства» архива.

Из приведенного окна желаемый файл можно мышкой сразу перетащить в нужное место.

Утилита эта расползлась по пиратским дискам после того, как сколько-нибудь функциональный фрагмент MS Office перестал помещаться без сжатия на один CD. С ее помощью можно было произвести инсталляцию прямо с компакт-диска, не распаковывая архив на винчестер. Сейчас, конечно, на рядовых жестких дисках в 40 Гбайт место можно не экономить. Для Windows XP эта проблема тоже неактуальна. Зато, упаковав редко используемые данные, можно избавить Win9x от необходимости продираться при поиске файлов через слишком ветвистое дерево, а при необходимости всегда можно обеспечить доступ как к папке. Так что исправленный ZipMagic4 еще пригодиться.

Итак, подробный анализ полученного LOG-файла показал единственный участок (рис. 3), где открытие файла (Open) AVWIN.LOG не сопровождается операцией Close. Остальные пары Open-Close и Lock-Unlock в порядке. Поскольку перед некорректной операцией идет интенсивное обращение к DLL-библиотекам zmrar и zmunrar, то ошибка скорее всего в них. Удаление или переименование любого из этих файлов решает проблему до получения исправленной версии. А там и новые глюки подоспеют.