Отвечает Сергей Мороз

Описанная ситуация весьма типична для некоторых приложений, написанных с использованием файловых СУБД типа MS Access. Характерные симптомы таковы: на файловом сервере Novell или Unix приложение работает нормально, но после переноса файлов баз данных на сервер Windows NT или Windows 2000 у некоторых клиентов могут возникать ошибки совместного доступа.

Причина в том, что сервер Novell по умолчанию никогда не ставит блокировки (file locks) на файлы, открытые клиентом только для чтения (read-only), если клиент не указывает этого специально. Приложения же MS Access, как правило, при открытии таблиц «только для чтения» никаких блокировок от файлового сервера явно не требуют. Таким образом, открытые для чтения файлы не блокируются, и совместная работа не нарушается.

На платформе же NT/2000 клиент и сервер совместными усилиями реализуют логику автоматической блокировки файлов, известную под названием Opportunistic Locks. Суть ее в том, что, даже когда программа-клиент, работающая на компьютере Windows NT/2000, открывает файл на сервере только для чтения и не требует эксклюзивного доступа (блокировок), сетевая поддержка (редиректор) клиентской машины все равно присылает на сервер запрос на специальный вид блокировки — Opportunistic Lock (сокращенно — oplock). При этом файл на сервере блокируется. Если после этого кто-то еще попытается открыть тот же самый файл для чтения (или для записи), то сервер спрашивает согласия клиента, открывавшего файл ранее. Если клиент согласие дает (а так обычно и происходит), то тип блокировки изменяется на Oplock Level II — для совместного чтения или Write Lock — для записи. Обычно работу этого механизма никто не замечает. Он подробно описан в Knowledge Base, статьи Q296264 (W2000) и Q129202 (NT3.5-4.0). Включается данный механизм только при условии, что с обеих сторон (клиентской и серверной) используется платформа Windows NT/2000.

Если у вас возникают проблемы с доступом, можно попробовать отключить механизм Oplocks. Проще всего это сделать на файловом сервере — раздел реестра для серверов Windows NT4 и Windows 2000 один и тот же. Необходимо запустить на сервере REGEDIT.EXE, открыть раздел HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesLanmanServer Parameters и создать в нем отсутствующий по умолчанию параметр EnableOplocks типа REG_DWORD. Установка его значения в 0 запрещает Oplocks.

Можно запретить механизм Oplocks и на клиентах, но это придется делать на всех клиентах, обращающихся к одному и тому же файлу. Для клиента Windows NT нужно открыть раздел HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesLanmanWorkstation Parameters и создать параметр UseOpportunisticLocking типа REG_DWORD со значением

равным 0. Для клиента Windows 2000 следует открыть раздел HKEY_LOCAL_MACHINESystem CurrentControlSetServicesMRXSmb Parameters и создать параметр OplocksDisabled типа REG_DWORD со значением 1.

После модификации всех перечисленных ключей реестра компьютер необходимо перезагрузить.

К сожалению, ни в BackOffice Server 2000, ни в BackOffice Server 2000 Resource Kit нет средств, позволяющих управлять настройками службы Microsoft Shared Fax по расписанию. Поэтому вы можете применить другой метод, который, кстати, пригоден для управления почти любыми продуктами, запускаемыми как службы Windows NT/2000: модификация реестра по расписанию с последующим перезапуском соответствующей службы. Для этого необходимо знать, во-первых, какие параметры реестра отвечают за настройки соответствующей службы, а во-вторых — полное название службы по-английски. Для того чтобы посмотреть названия всех служб, запущенных на машине, проще всего набрать в DOS-сессии команду «net start» без дополнительных параметров.

Теперь поясним механизм непосредственно на примере Microsoft Shared Fax. Для выполнения процесса конфигурации службы создается два .bat-файла приблизительно следующего содержания:

Regedit.exe /I /s /enable.reg
Net stop "Microsoft Shared Fax"
Net start "Microsoft Shared Fax"
И
Regedit.exe /I /s /disable.reg
Net stop "Microsoft Shared Fax"
Net start "Microsoft Shared Fax"

В первом примере упоминается текстовый файл «enable.reg», который нужно создать отдельно. Он должен содержать соответствующий параметр реестра, установленный в значение, предусматривающее прием звонков службой Microsoft Shared Fax. Команда «regedit.exe /i /s enable.reg» импортирует этот файл в реестр (при необходимости перед именем .reg-файла нужно указать полный путь!), а команды «net stop» и «net start» перезапускают службу Shared Fax. Службу необходимо перезапускать потому, что практически все программные продукты, запускаемые как службы и хранящие свои установки в реестре, за редким исключением, считывают их из реестра только в момент запуска. Приведенный пример .bat-файла является стандартным.

Во втором .bat-файле все аналогично, за исключением того, что в реестр импортируется файл «disable.reg», в котором тот же самый параметр должен быть установлен в значение, запрещающее прием звонков. И также перезапускается служба. Далее, файл enable.bat должен запускаться каждый вечер в фиксированное время с помощью любой службы расписания. Удобнее всего для этого использовать службу Task Scheduler, которая настраивается через панель управления: Control Panel — Scheduled Tasks. Файл disable.bat должен запускаться тем же способом каждое утро. Службу Task Scheduler, кстати, можно настроить так, чтобы в рабочие и выходные дни расписание включения/выключения факс-модема было различным.

Теперь о содержании .reg-файлов.

Подходящих параметров реестра у службы Microsoft Shared Fax два: один позволяет включать/выключать прием факсов на уровне отдельного устройства (факс-модема), другой — на уровне всей службы в целом. Удобнее всего делать это на уровне службы. Примеры необходимых .reg-файлов приведены на Экранах 1 и 2.

Экран 1. Пример файла, разрешающего прием звонков.

Режим работы службы Microsoft Shared Fax задается значением параметра QueueState: 0 — разрешает отправку и прием факсов службой, 1 — запрещает только прием, 4 — запрещает только отправку, 5 — запрещает и то и другое.

Экран 2. Пример файла, запрещающего прием звонков.

Создать .reg-файлы самостоятельно очень легко: требуется запустить regedit.exe, найти необходимый раздел реестра (см. Экран 1 и Экран 2) и выполнить операцию Export Registry File. После этого следует открыть полученный файл любым текстовым редактором и удалить все строчки, кроме тех, которые нужны. Необходимо сделать две копии .reg-файла с разными названиями и разными значениями параметра QueueState. Данный метод, кстати, также позволяет при отсутствии документации определить, какие параметры нужны и какие значения они могут принимать, если вы сравните содержание реестра до и после изменения настройки программного продукта стандартными средствами. Оба .reg-файла проще всего сохранить в каталоге WINNT — в этом случае в команде «regedit /i /s enable.reg» не придется прописывать полный путь перед именем .reg-файла.

Ну и, наконец, при желании, запрет и разрешение приема звонков в Microsoft Shared Fax можно реализовать не на уровне службы, а на уровне отдельного устройства (факс-модема). Пример .reg-файла (разрешающего) приведен на Экране 3.

Экран 3. Пример файла, разрешающего прием звонков на уровне устройства.

Состояние модема задается параметром Flags: 0 — запрещены и прием и передача, 1 — разрешен только прием, 2 — разрешена передача, 3 — разрешено и то и другое. Обратите внимание, что идентификатор устройства (на рисунке выделен) на разных компьютерах может от приведенного выше отличаться.