Иногда бывает необходимость проверить, заблокирован ли файл каким-то приложением в монопольном режиме, прежде чем совершать какое-то действие над ним. Например, мой скрипт Get-PsFCIV.ps1 очень сильно ругается краснотой, если файл заблокирован, т.к. System.IO.StreamReader, который у меня используется для подсчёта хешей файлов требует, чтобы файл никем не был занят. Принцип проверки файла заключается в том, что мы пробуем получить доступ к файлу через System.IO.StreamReader и если это нам не удалось, значит файл заблокирован. Вот и решил написать такой удобный фильтр, который можно использовать и отдельно, просто для проверки блокировки файлов:

filter Test-FileLock {
    # проверяем, откуда пришли данные - из конвейера или через аргументы фильтра
    # и создаём объекты текущего элемента
    if ($args[0]) {$filepath = gi $(Resolve-Path $args[0]) -Force} else {$filepath = gi $_.fullname -Force}
    # отфильтровываем папки
    if ($filepath.psiscontainer) {return}
    # задаём переменную $locked в исходное значение $false
    $locked = $false
    # создаём ловушку для ошибки доступа. Если ловушка сработает, то переменная 
    # $locked выставляется в $true, что будет означать, что файл заблокирован
    # в монопольном режиме каким-то приложением
    trap {
        Set-Variable -name locked -value $true -scope 1
        continue
    }
    # открываем файл в режиме read/write. Если файл заблокирован, то ошибка будет
    # поймана ловушкой
    $inputStream = New-Object system.IO.StreamReader $filepath
    # если файл не был заблокирован, то закрываем StreamReader
    if ($inputStream) {$inputStream.Close()}
    # выводим результаты на экран в виде хеш-таблицы
    @{$filepath = $locked}
}

фильтр можно запускать как с аргументами, так и в конвейере:

[↓] [vPodans] Test-FileLock ntuser.dat

Name                           Value
----                           -----
C:\Users\vPodans\ntuser.dat    True


[↓] [vPodans] Test-FileLock ntuser.ini

Name                           Value
----                           -----
C:\Users\vPodans\ntuser.ini    False


[↓] [vPodans] dir ntuser.dat -Force | Test-FileLock

Name                           Value
----                           -----
C:\Users\vPodans\ntuser.dat    True


[↓] [vPodans] dir ntuser.ini -Force | Test-FileLock

Name                           Value
----                           -----
C:\Users\vPodans\ntuser.ini    False


[↓] [vPodans]

надеюсь, этот фильтр кому-нибудь сгодится ещё :-)

Короткая заметка.

Я достаточно часто встречаю задачу централизованной установки политики исполнения скриптов PowerShell в домене и очень часто люди решают её используя правку реестра, что является идеологически неверным подходом. Я не раз говорил, что для централизованной настройки параметров следует использовать групповые политики на сколько это возможно, поскольку они обладают полезными свойствами:

• единая точка управления;
• охват множества компьютеров, совершая минимум движений;
• читабельность настроек и возможность их сохранения/восстановления;
• если настройки на какой-то машине были сбиты или изменены – политика перезапишет изменения на значения, которые установил администратор в групповой политике.

Однако, не везде у нас есть возможность использования такой настройки через GP, поскольку такая настройка есть только в ОС, в которых PowerShell поставляется по умолчанию – это Windows Server 2008, Windows Server 2008 R2 и Windows 7. Для остальных ОС такой настройки нету в политиках. Но не всё так плохо, как может показаться:

>> Administrative Templates for Windows PowerShell <<

Вам достаточно установить этот шаблон на компьютер, с которого вы управляете групповыми политиками. Данная политика будет размещена в секции: Computer Configuration –> Administrative Templates –> Windows Components –> Windows PowerShell.

Этот шаблон устанавливается на ОС не ниже Windows XP.

Мне вчера на почту пришёл комментарий на пост: Смена владельца папки или файла в PowerShell (часть 2), в котором сообщалось об ошибке, которую генерирует скрипт, если в пути есть служебные мета-символы, как апостроф (одиночкая кавычка). А дело было в том, что этот мета-символ нужно дополнительно эскейпить (помимо обратных слешей в пути). То же касается и квадратных скобок. Одиночные кавычки эскейпятся очень просто – одним обратным слешем:

В своём предыдущем блоге я писал заметку про то, как можно случайно удалить классы WMI – PowerShell - убийца WMI классов? И недавно узнал, как можно восстановить эту функциональность обратно. Сами Win32 классы находятся в библиотеке CIMWIN32.MOF, которая и повреждается при удалении классов. Чтобы вернуть эти классы – достаточно перекомпилировать эту библиотеку:

C:\Windows\System32\wbem\MOFComp CIMWIN32.MOF

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

PSFCIV_0.85
PS1 file (25.6 kb)

Итак, как с этим скриптом начинать работать. В скрипте есть 3 обязательных параметра: путь к папке, которую нужно посчитать или проверить, путь к XML файлу (если файла нету, то он будет создан) и как минимум 1 алгоритм хеширования. Т.е. минимум это должно выглядеть вот так:

.\PSFCIV_0.85.ps1 C:\Temp –xml DB.XML –sha1

При этом можно указать алгоритм –md5 или оба сразу (-sha1 –md5). В таком случае для каждого файла будет сгенерировано 2 хеша. Без указания любого из этих параметров будет сгенерирована ошибка и работа будет остановлена.

Опциональные параметры:

• -Include file.ext – будет произведена проверка только указанного файла;
• -Recurse – будет произведена проверка всех файлов в папке и подпапках;
• -Rebuild – особый режим обновления XML файла, из которого будут удалены устаревшие записи и если есть новые файлы в папке или папках, то они будут добавлены в XML файл. Данный ключ требует наличия XML файла. Если файл БД не будет обнаружен, то будет выведена соответствующая ошибка. При этом режиме проверка целостности файлов не проверяется.
• -Verbose brief/full – включает один из режимов вывода информации о ходе проверки на консоль. Можно выбрать Brief – упрощённый или Full – максимальный.
• -Show Total/New/Ok/Bad/Miss – включает дополнительный режим вывода на экран одной из выбранных категорий. Например, всех проверенных файлов, только новых файлов, которые добавлены в БД, только файлов, которые прошли проверку, только файлы с несоответствующим хешем или только файлы, для которых есть запись в БД, но самого файла уже нету.
• -Force Rename/Delete – включает режим действия над проблемными файлами. Можно выбрать – переименования (тогда к файлу будет добавлено расширение .BAD) или удаления файла.

На данном этапе реализована работа в соответствии с логикой (которая описана тут: PS FCIV (часть 1)) и односторонняя совместимость с FCIV. Т.е. этой утилите можно скармливать XML файл, который сгенерирован с помощью этого скрипта. В скрипте начата реализация поддержки альтернативных БД, которые не совместимы с FCIV XML. Плюс планируется обеспечение двусторонней поддержки FCIV – т.е. скрипт сможет корректно воспринимать и обрабатывать XML файлы, которые сгенерированы утилитой FCIV. Ну и оптимизация самого кода. Сам скрипт снабжён достаточно плотными комментариями, поэтому будет совсем нетрудно с ним разобраться. По мере дописывания кода буду выкладывать более актуальные версии файла.

Update 27.07.2009

• Скрипт PsFCIV.ps1 переписан в виде Advanced Function под именем Get-PsFCIV. Теперь его достаточно загрузить в консоль используя dot-sourcing.
• Добавлена справка для функции. После загрузки функции в консоль достаточно набрать команду: Get-Help Get-PsFCIV
• По умолчанию на экран не выводится никакой информации, а только коды возврата. Коды возврата описаны в справке.
• Изменён ключ -Verbose. Теперь используется стандартный ключ -Verbose для вывода расширенной информации. Аргументы не принмаются.
• Добавлен стандартный ключ -Debug для вывода диагоностической информации.
• Добавлена поддержка обработки XML файла сгенерированного утилитой FCIV (т.е. совместимость с FCIV теперь двусторонняя).
• Ключ -Force заменён на ключ -Action с сохранением аргументов.
• К ключу -Show добавлен ещё один аргумент Unknown для индикации файлов с неопределённым результатом проверки. Такое состояние у файла может быть в случае, если не удалось сопоставить алгоритмы хеширования. Т.е. когда при вызове функции указывается алгоритм –SHA1, но в XML файле есть только MD5 хеш и наоборот.

PSFCIV_0.88
PS1 file (32.5 kb)