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

У меня есть два файловых сервака (Win2000AS и WinNT4.0), за которыми мне очень неохота следить. На одном из серверов крутятся базы 1С:Предприятия, а другой - просто файл-сервер для пользовательской всяко-всячины. Так вот, как показала практика, в случае чего именно эти сервера доставляют мне больше всего хлопот. Мало того, что машинное время они жрут как черная дыра, так еще и являются самыми слабыми (в плане безопасности) объектами сети. Помнится, пробрался к нам в интранет Клещ - так я эти серваки потом долго вычищал. А вся причина в чем? Правильно, некому предупредить то, что в общих каталогах появилась куча новых файлов.

Историй про полезность файлового мониторинга у меня еще много, но не будем заострять на этом внимание. Пусть применение новой фичи будет вашим домашним заданием.

В поисках решения

Дальше речь пойдет, по большей части, о решении на языке С. Не расстраивайтесь, если вы мало что в этом понимаете. Главное в решении - уловить суть.

Функция ReadDirectoryChangesW имеет следующий прототип:

BOOL ReadDirectoryChangesW( HANDLE hDirectory, LPVOID lpBuffer, DWORD nBufferLength, BOOL bWatchSubtree, DWORD dwNotifyFilter, LPDWORD lpBytesReturned, LPOVERLAPPED lpOverlapped, LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine ); 

• hDirectory - дескриптор каталога за которым мы должны следить. Получить дескриптор можно с помощью WinAPI функции OpenFile (см. ниже).
• lpBuffer - указатель на буфер, в который будет помещена информация о произошедших изменениях в каталоге.
• nBufferLength - длина буфера. С расчетом этой величины у меня были некоторые проблемы, по этому мы остановимся на буфере чуть позже.
• bWatchSubtree - булево значение, указывающее на необходимость слежения за вложенными каталогами.
• dwNotifyFilter - набор флагов, который определяет характер изменений, которые нас интересуют.
• lpBytesReturned - указатель на переменную, в которую функция ReadDirectoryChangesW() запишет значимую длину данных в буффере lpBuffer.
• Аргументы lpOverlapped и lpCompletionRoutine нас, в данном случае, не интересуют.

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

HANDLE hDir = CreateFile(szDirPath,FILE_LIST_DIRECTORY, 	FILE_SHARE_READ|FILE_SHARE_DELETE,NULL, 	OPEN_EXISTING,FILE_FLAG_BACKUP_SEMANTICS,NULL); 

С буфером дело обстоит сложнее. По сути, буффер имеет вид массива из экземпляров структуры типа FILE_NOTIFY_INFORMATION. Каждый экземпляр описывает некое событие, которое имело место в пределах каталога. Дело осложняется еще и за счет того, что одно событие не ограничивается FILE_NOTIFY_INFORMATION, а требует еще и выделения памяти под имя файла. Если кто не догоняет, ниже я привел прототип структуры FILE_NOTIFY_INFORMATION

typedef struct _FILE_NOTIFY_INFORMATION { DWORD NextEntryOffset; DWORD Action; DWORD FileNameLength; WCHAR FileName[1]; } FILE_NOTIFY_INFORMATION; 

sizeof(FILE_NOTIFY_INFORMATION) + MAX_PATH * 2 

Но не думайте, что все так просто. У нас еще не определено количество таких объемов, необходимое для представления нескольких событий. Вообще, результат работы функции ReadDirectoryChangesW определяется кодом возврата и значением переменной lpBytesReturned (см. прототип функции выше). Если lpBytesReturned после успешного (определяется кодом возврата) выполнения функции равно нулю, то системе не хватило буффера для размещения информации о всех произошедших изменениях. Самое интересное, это ремарка в документации о том, что нужно делать в этом случае - ну, мол, не переживайте? перечитайте каталог и проверьте все сами. Класс! Это при условии вложенности каталогов! Да еще и для сравнения нужно предварительно собрать данные и где-то их сохранить. Таким макаром проще юзать Find*ChangeNotification - алгоритм нисколько не упрощается.

Но, русские не сдаются! Так как ничего полезного о расчете буфера в документации я не нашел и в инете никто не пособил, пришлось идти на таран. Методом научного тыка я пришел к выводу, что более 3-4 событий функция ReadDirectoryChangesW одновременно не обрабатывает. Да и то, 3-4 события это когда функция вызывается с фильтром по максимуму, то есть следит за изменениями атрибутов, сменой имен, созданием и прочими действами. Конечно, тут я могу и ошибаться, но как тут еще протестировать - для объективности необходимо выполнять изменения в каталоге с бешенной скоростью. Для пущей надежности мы будем резервировать место под 32 события (учитывая, что еще под имя файла отводится по максимуму, даже если будут иметь место более 32, то все равно на вряд-ли загнемся от недостатка памяти).

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

Соединяем с perl

Механизм XSUB подразумевает собой некий стандарт, следуя которому можно соединить программу на C и perl. Большая часть усилий по сопряжению двух языков приходится на С-часть программы. То есть изучая механизм XSUB вы должны всегда понимать, что речь идет о коде на C. По большей части весь механизм заключается в правильной работе со стеком аргументов и приведении типов к типам perl (то есть скаляр, массив, хэш). Что бы не держать в голове все тонкости правил передачи аргументов и уменьшить количество ошибок, связанных с аргументацией, был разработан специальный макроязык описания интерфейсов функций XSUB. Этот язык содержит макросы, которые в процессе обработки преобразуют код программы в соответствии с требованиями XSUB. Часть этих макросов обрабатывается препроцессором С перед компиляцией, а часть специальной программой xsubpp, которая выполняет преобразование файла с кодом XSUB к полноценному С-коду. По сути, xsubpp представляет собой компилятор XSUB.

Для создания макета нового модуля воспользуемся программой h2xs. Перейдите в каталог, в котором будет размещен проект и наберите в командной строке следующую команду

h2xs -A -n WCN 

Итак, файл WCN.xs представляет собой гибрид С-кода и макроязыка XSUB. Именно в этом файле должен быть описан интерфейс модуля, то есть правила интерпретации входных и выходных значений для всех функций, через которые perl будет взаимодействовать с нашим модулем.

#include "EXTERN.h" #include "perl.h" #include "XSUB.h" #define _WIN32_WINNT 0x0400 MODULE = WCN		PACKAGE = WCN		 HANDLE Open(szDirPath) LPCTSTR szDirPath; 	CODE: RETVAL = CreateFile(szDirPath,FILE_LIST_DIRECTORY, 	FILE_SHARE_READ|FILE_SHARE_DELETE,NULL, 	OPEN_EXISTING,FILE_FLAG_BACKUP_SEMANTICS,NULL); 	OUTPUT: RETVAL BOOL Close(hDir) HANDLE hDir; 	CODE: RETVAL = CloseHandle(hDir); 	OUTPUT: RETVAL void Read(hDir,bWatchSubtree,dwFilter) HANDLE hDir; BOOL bWatchSubtree; DWORD dwFilter; 	INIT: DWORD dwBytesReturned; DWORD dwRecSize = 	sizeof(FILE_NOTIFY_INFORMATION) + MAX_PATH * 2; DWORD dwCount = 32; FILE_NOTIFY_INFORMATION *pCurrNI; FILE_NOTIFY_INFORMATION *pNI; BOOL bResult; char buf[MAX_PATH]; AV* NotifyInfo; 	PPCODE: pNI = (FILE_NOTIFY_INFORMATION*) 	malloc(dwRecSize * dwCount); bResult = ReadDirectoryChangesW( 	hDir,pNI,dwRecSize * dwCount,bWatchSubtree, 	dwFilter,&dwBytesReturned,NULL,NULL); if (bResult && dwBytesReturned){ 	pCurrNI = pNI; 	while (1){ 		memset(buf,0,sizeof(buf)); 		WideCharToMultiByte(CP_ACP,0,pCurrNI->FileName, 			pCurrNI->FileNameLength,buf,sizeof(buf), 			NULL,NULL); 		NotifyInfo = (AV*)sv_2mortal((SV*)newAV()); 		av_push(NotifyInfo,newSViv(pCurrNI->Action)); 		av_push(NotifyInfo,newSVpv(buf, 			pCurrNI->FileNameLength / 2)); 		XPUSHs(newRV_noinc((SV*)NotifyInfo)); 		if (!pCurrNI->NextEntryOffset){ 			break; 		}else{ 			pCurrNI = (FILE_NOTIFY_INFORMATION*) 				((DWORD)pCurrNI + pCurrNI->NextEntryOffset); 		} 	} }else{ 	XPUSHs(Nullsv); } free(pNI); 

BOOL		T_IV HANDLE		T_UV DWORD		T_UV LPCTSTR		T_PV 

perl Makefile.PL ... nmake ... 

Модуль WCN.pm

package WCN; require 5.005_62; use strict; use warnings; require Exporter; require DynaLoader; our @ISA = qw(Exporter DynaLoader); # Items to export into callers namespace by default. Note: do not export # names by default without a very good reason. Use EXPORT_OK instead. # Do not simply export all your public functions/methods/constants. our @EXPORT = qw( 	&WCN_INVALID_HANDLE 	&WCN_FILE_NAME 	&WCN_DIR_NAME 	&WCN_ATTRIBUTES 	&WCN_SIZE 	&WCN_LAST_WRITE 	&WCN_LAST_ACCESS 	&WCN_SECURITY 	&WCN_ACTION_ADDED 	&WCN_ACTION_REMOVED 	&WCN_ACTION_MODIFIED 	&WCN_ACTION_RENAMED_OLD_NAME 	&WCN_ACTION_RENAMED_NEW_NAME ); our $VERSION = '0.01'; bootstrap WCN $VERSION; # Preloaded methods go here. sub WCN_INVALID_HANDLE()	{0xFFFFFFFF} sub WCN_FILE_NAME()		{0x00000001} sub WCN_DIR_NAME()		{0x00000002} sub WCN_ATTRIBUTES()		{0x00000004} sub WCN_SIZE()			{0x00000008} sub WCN_LAST_WRITE()		{0x00000010} sub WCN_LAST_ACCESS()		{0x00000020} sub WCN_SECURITY()		{0x00000100} sub WCN_ACTION_ADDED()		{0x00000001} sub WCN_ACTION_REMOVED()	{0x00000002} sub WCN_ACTION_MODIFIED()	{0x00000003} sub WCN_ACTION_RENAMED_OLD_NAME(){0x00000004} sub WCN_ACTION_RENAMED_NEW_NAME(){0x00000005} sub new{ 	my $class = shift; 	$class= ref($class) || $class; 	my $self = {}; 	bless $self,$class; 	return $self if $self->initialize(@_); 	return undef; } sub initialize{ 	my ($self,$path,$tree,$filter) = @_; 	$path = '.' unless defined($path); 	$tree = 0 unless defined($tree); 	$filter = WCN_FILE_NAME unless defined($filter); 	$self->{path} = $path; 	$self->{tree} = $tree; 	$self->{filter} = $filter; 	Close($self->{handle}) if exists($self->{handle}) && 		$self->{handle} != WCN_INVALID_HANDLE; 	$self->{handle} = Open($path); 	return undef if $self->{handle} == WCN_INVALID_HANDLE; 	return 1; } sub read_changes{ 	my $self = shift; 	return undef if $self->{handle} == WCN_INVALID_HANDLE; 	return Read($self->{handle},$self->{tree},$self->{filter}); } DESTROY{ 	my $self = shift; 	Close($self->{handle}) if $self->{handle} != WCN_INVALID_HANDLE; } 1; __END__ 

На самом деле, константы, которые определены в модуле константными функциями (WCN_**) можно было импортировать из программы на C. Но после того, как я посмотрел на реализуцию кода С и распухания модуля WCN.pm при использовании стандартного механизма переноса констант, я решил что гораздо эффективнее объявить константы прямо в модуле. Не волнуйтесь, значения этих констант навряд-ли изменяются от версии к версии в Windows NT. Иначе очень многие программы написанные на С просто не работали после переноса.

Теперь давайтеразберемся, как же работает модуль. Прежде всего, конструктор создает экземпляр объекта и инициализирует его. В последствии, объект может быть переориентирован на мониторинг другого каталога. Это достигается путем вызова метода initialize() с соответствующими аргументами.

Вызов метода read_changes() приводит к блокировке программы до возникновения нового события. В качестве результата, метод read_changes возвращает результат работы функции Read() из С-модуля. При обращении к методу read_changes() модуль WCN.pm сам передает ранее сохраненные аргументы в функцию на C. Массив, возвращаемый С-функцией Read() представляет собой последовательность ссылок на анонимные массивы, каждый из которых в свою очередь описывает событие, имевшее место в каталоге. Первый элемент этого анониманого массива содержит код события. Символические константы WCN_ACTION_* облегчают процесс идентификации событий (необходимо заметить, что из модуля экспортируются только имена констант, но не методов и функций). Второй элемент массива представляет собой имя файла. Имя файла представляется путем к файлу, относительно каталога слежения. То есть, если изменения произошли в корне каталога, то имя файла представляет истинное имя файла, подвергшегося изменениям. Если же изменения произошли в одном из подкаталогов, то имя файла включает в себя имена всех каталогов, которые представляют путь к файлу относительно каталога слежения.

Для полного комплекта пакету недостает функции тестирования. Файл test.pl будет вызываться каждый раз, когда в процессе инсталяции модуля будет выполняться команда

nmake test 

my $watcher = new WCN('C:\\temp',1,WCN_ATTRIBUTES|WCN_SIZE) 	or die "Не могу поднять ногУ!\n"; while(1){ 	my @changes = $watcher->read_changes(); 	die "Облажались!\n" if ref($changes[0]) ne 'ARRAY'; 	 	foreach my $ref (@changes){ 		print "Событие: ${$ref}[0], Файл/Каталог: ${$ref}[1]\n"; 	} }