2016-04-14 5 views
3

У меня есть список всех дескрипторов файлов всех процессов, как я могу узнать, какие из этих дескрипторов фактически блокируют файл?Проверьте, заблокирован ли файл файловой системой процесса

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

Желательно, чтобы я увидел решение, которое работает в Windows XP и выше.

Я уже искал функцию GetFileInformationByHandleEx, но я ничего не мог найти о разрешениях доступа. :/

Редактировать: Мне не нужна информация в реальном времени о блокировке файла. Файлы, над которыми я планирую работать, будут заблокированы до тех пор, пока определенные приложения не будут закрыты или вообще не будут заблокированы.

+3

Лучше просить прощения, чем разрешение –

+0

Вы можете прочитать «блокировку» файла, пытаясь записать его в дескриптор, поскольку чтение/запись осуществляется только владельцем дескриптора. – Joel

+7

Невозможно сделать это. Любая функция IsFileLocked() не может надежно работать в многозадачной операционной системе. Возвращаемое значение моментально устарело и не гарантирует, что оно все еще разблокируется при попытке доступа к файлу. Вы узнаете, обратившись к файлу, который является атомарным. Это не является неэффективным, только то, что вы делаете, когда оно заблокировано, может быть. Это то же самое, что и вы, если гипотетическая функция IsFileLocked() вернула TRUE. Избегайте всего этого, препятствуя тому, чтобы другой процесс блокировал файл при его открытии. –

ответ

0

Этот вопрос является дубликатом Win32 files locked for reading: how to find out who's locking them.

Кроме того, комментарий Ханса Пассана верен: запрос на заблокированное состояние любого файла Win32 дает устаревшую информацию. Несоблюдение этого предупреждения вызовет труднодоступные ошибки.

Если вы управляете всеми битами кода, которые, по вашему мнению, будут обращаться к файлам, лучше использовать named pipe для межпроцессного взаимодействия вместо запроса заблокированных файлов.

+0

Не совсем дубликат. Меня интересуют не только блокировки чтения. Меня интересует любой замок. удалять, записывать, читать и блокировать блокировку определенной области в файле. И снова это действительно не имеет значения, насколько устаревшая эта информация. И я не планирую перерабатывать процессы, чтобы внедрять функциональные возможности трубопроводов и многое другое. – Forivin

0

Вы можете использовать NtQueryObject API, чтобы получить информацию о ручке, включая следующие:

ULONG Attributes; 
ACCESS_MASK GrantedAccess; 

Или вы можете получить доступ к той же информации, используя NtQueryInformationFile с помощью FileModeInformation и FileAccessInformation значения для FileInformationClass параметра.

+0

Я создал множество тестовых файлов и создал на них ручки с каждой комбинацией чтения/записи/удаления и доступа к записи.Затем в другом приложении, которое выполняется с помощью SeDebugPrivilege и т. Д., Я проверил GrantedAccess, Attributes, Flags и т. Д. Вот результат: http://i.snag.gy/uHOMr.jpg Я думаю, можно с уверенностью сказать, что ни один из них не содержит никаких полезную информацию о состоянии блокировки. – Forivin

Смежные вопросы