Кто с этим имел дело или примерно представляете куда
копать  - подскажите?

Суть следующая: 
файл находится на NT-образном сервере, открыт все время для 
чтения клиентами с разных рабочих станций (win9x, NT-образные),
перед чтением клиенты лочат нужный блок файла ф-цией LoсkFile,
после чтения - разлочивают. Бывают ситуации когда разлочивания
не происходит, в рез-те серверное приложение не может получить
доступ ко всему файлу. Что нужно делать чтобы узнать что файл 
открыт и держится другим процессом и как его отцепить - 
я представляю (начинать с юзания ф-ций NTQuery...).

Вопрос: как узнать что файл залочен ф-цией LockFile и как его
насильно разлочить?

P.S. Сам факт залочивания Computer Management  отображает в
\System Tools\Open Files\ колонка "Locks".

 

а если UnlockFile вызвать? 

Клиент, который залочил файл - не может этого
сделать, т.к. висит.
На серверном приложении это эффекта на даст,
т.к. оно не может при помощи этой ф-ции
снять чужую блокировку.

Возможно я не корректно сформулировал вопрос, перефразирую:
То что файл залочен кем-то видно по коду возврата из ф-ции LockFile,
как узнать какой процесс его залочил? 

А зачем вообще лочить файл для чтения?
Лочить нужно только для записи.
А читать можно спокойно всем вместе. Главное на чтение открывать с флагом ShareDenyNone. 

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

Блокировка точно при помощи LockFile? Если да, то щас подумаю что можно сделать... 

Придумал:

Вроде неплохо получилось - надо будет оформить ввиде статейки... Видимо таким же образом действует програмка Unlocker. Код конечно не супер, надо кое-где проверку на ошибки добавить, да и процесс у которого мы закрыли хендл может потом себя не корректно повести. 
ЗЫ извините за второе наподряд сообщение... 

Это сообщение отредактировал(а) Nickel - 18.4.2006, 18:58

Спасибо, завтра потестирую код (сегодня - на рыбалку еду).
Программа Unlocker, действительно хорошая программа,
она закрывает файлы, открытые сетевыми клиентами,
другие программы, которые я нашел в Инете с исходным кодом - этого не 
могли делать, т.к. работали через CreateRemoteHandle,
и вызывать эту ф-цию в данном случае приходилось для процесса
System, что, как я понимаю запрещено. 

Спасибо, работает, только на некоторых процессах на некоторых файлах 
программа зависает в ф-ции QueryObject.
Видимо нужно поразбираться с правами доступа в поле GrantedAccess. 

С зависаниями разобрался, GrantedAccess не при чем, зависает на pipe, которые 
открыты в блокирующем режиме и находятся в ждущем режиме.
Но вопрос так и остался открытым, прямого отношения к блокировкам через ф-цию LockFile
приведенный код отношения не имеет. С файлами, открытыми и заблокированными локальными
процессами - все ОК, а вот с файлами открытыми клиентами по сети - блокировка остается, 
хотя хэндл, принадлежащий процессу System (т.к. по сети), закрывается. Следовательно
по прежнему не можем его нормально читать.

И еще интересный момент: ф-ция CopyFile благополучно копирует залоченный
файл со всем его содержимым, чихая на блокировку части данных. 
Может кто знает как она это делает? 

Очень даже имеет: мы закрываем хендл файла, который залочен, (надо сказать довольно необычным способом через DuplicateHandle)  и блокировка пропадает вмсете с хендлом. Кстати ты под какой виндой пробуешь? У меня на XP sp2 system не открывается с PROCESS_DUP_HANDLE а когда беру привелегии отладчика ловлю нехилый подвисон моей проги. Мб всё-таки проблема что хендл не закрывается?
 
LockFile блокирует часть файла только на запись. 

У меня система WinXP SP2, system открывается с PROCESS_DUP_HANDLE 
с привилегиями отладчика, никаких зависаний с этим нет.
Хэндл у залоченного файла успешно закрывается, 
это показывает и прога Unlocker, и монитор 
procexplorers от Sysinternals, но когда серверное приложение 
пытается залочить файл для записи возвращается ошибка о том
что другой процесс залочил файл. Даже в фаре нажимаем F3,
чтобы поглядеть содержимое файла - он показывает пустое окно.

И еще - ф-ция NTQueryObject при попытке получения имени файла
взвисает на pipe'ах так что даже если ее поместить в поток, то поток
потом не убивается, вследствие чего не убивается процесс ничем,
кроме перезагрузки системы. Ф-ция же NTQueryInformationFile,
взвисает на pipe'ах не так смертельно, поток можно убить, но 
имя файла она возвращает без имени диска...  А то что я юзаю
ф-ции NT... вместо Zw... может иметь какое-то значение? 

Пайп, это объект ядра и он не принадлежит процессу. Зависание происзходит на синхронных Трубах, которые, имея приоритет выше, чем твое приложение, отпустят поток только после завершения своей операции...