Отслеживание изменений на дисках

Есть пример кода позволяющий отслеживать изменения на диске.
здесь
Помогите с реализацией отслеживания изменений не на одном диске, а на пример на двух или трёх одновременно.
Заранее спасибо !

ИМХО можно чуток попроще

FUNCTION PBMAIN() AS LONG
   LOCAL lDir AS DWORD
   LOCAL lFound1 AS DWORD
   LOCAL lFound2 AS DWORD
   DO
     lDir = FindFirstChangeNotification("c:\prg\", %true, %FILE_NOTIFY_CHANGE_SIZE)
     DO
         lFound1 = WaitForSingleObject(lDir, 100)
         CALL DoEvent
     LOOP WHILE lFound1 <> 0
     DO
        MSGBOX "Change detected!" & TIME$
        lFound2 = FindNextChangeNotification(lDir)
        lFound2 = WaitForSingleObject(lDir, 100)
        EXIT DO
     LOOP
     lFound2 = FindCloseChangeNotification(lDir)
     CALL DoEvent
   LOOP
END FUNCTION

инициализируйте FindFirstChangeNotification на столько директорий на сколько надо

Не смог разобратся что с этим делать !

Все есть в FAQ: Мониторинг изменений на диске

Я понимаю что я что то не догоняю.
Помогите пожалуйста !
Там вроде с одним диском можно одновременно работать, а мне надо с несколькими !

Ну создавай код в потоке для каждого из дисков...

Если честно пробовал.
Вот потому и интересуюсь другим способом.

Цитата Petrov @ 19.01.07, 05:33

Не смог разобратся что с этим делать !

А что не понятно то?

вызываем API
FindFirstChangeNotification("c:\prg\", %true, %FILE_NOTIFY_CHANGE_SIZE)

первй параметр имя директории за которой следим

второй параметр - если TRUE то следить за изменениями в субдиректориях от данного пути

третий параметр один из(в зависимости от того что нужно):
FILE_NOTIFY_CHANGE_FILE_NAME - Any file name change in the watched directory or subtree causes a change notification wait operation to return. Changes include renaming, creating, or deleting a file name.
FILE_NOTIFY_CHANGE_DIR_NAME - Any directory-name change in the watched directory or subtree causes a change notification wait operation to return. Changes include creating or deleting a directory.
FILE_NOTIFY_CHANGE_ATTRIBUTES - Any attribute change in the watched directory or subtree causes a change notification wait operation to return.
FILE_NOTIFY_CHANGE_SIZE - Any file-size change in the watched directory or subtree causes a change notification wait operation to return. The operating system detects a change in file size only when the file is written to the disk. For operating systems that use extensive caching, detection occurs only when the cache is sufficiently flushed.
FILE_NOTIFY_CHANGE_LAST_WRITE - Any change to the last write-time of files in the watched directory or subtree causes a change notification wait operation to return. The operating system detects a change to the last write-time only when the file is written to the disk. For operating systems that use extensive caching, detection occurs only when the cache is sufficiently flushed.
FILE_NOTIFY_CHANGE_SECURITY - Any security-descriptor change in the watched directory or subtree causes a change notification wait operation to return.


после вызова АПИ возвращает хэндл "to a find change notification"
ждем в на WaitForSingleObject(хэндл "to a find change notification", 100)
и крутимся в цикле(вызывая переодически TranslateMessage и DispatchMessage чтобы окно не выглядело отмороженым)
если делать ожидание в потоке то можно и без цикла в вечном ожидании.
После первого изменения делаем что-то что надо и далее крутимся только
в FindNextChangeNotification.

Т.е. FindNextChangeNotification это как боёк на ружье, взвели и ждем,
сработало изменение опять взводим боёк и ждем.

вызывается FindNextChangeNotification и точно так же по возвращенному хэндлу ждем следующего изменения запуская переодически MessagePump если ожидание реализовано не в отдельном потоке.

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

Сообщение отредактировано: AlexJ - 19.01.07, 10:50

Спасибо, попробую !

AlexJ не могу никак воспользоватся вашим примером.
Компилятор ругается.
Помогите.

Здравствуйте. Вот код:

procedure TFormSkanerFile.SpeedButton2Click(Sender: TObject);
begin
 ChangeHandle:= FindFirstChangeNotification(PChar('C:\'), false, FILE_NOTIFY_CHANGE_FILE_NAME or FILE_NOTIFY_CHANGE_DIR_NAME or FILE_NOTIFY_CHANGE_ATTRIBUTES or FILE_NOTIFY_CHANGE_LAST_WRITE or FILE_NOTIFY_CHANGE_SIZE);
 if ChangeHandle <> INVALID_HANDLE_VALUE then
  begin
   while true do
    begin
     Application.ProcessMessages;
     if WaitForSingleObject(ChangeHandle,500) = WAIT_OBJECT_0 then
      begin
       MemoMonAktFileSys.Lines.Add(IntToStr(ChangeHandle) + ' Изменилось имя файла');
      end;
      if FindNextChangeNotification(ChangeHandle) = false then Break;
    end;
   FindCloseChangeNotification(ChangeHandle);
  end;
end;

А проблема то что у меня все время ChangeHandle возвращает одно и тоже число и я просто не могу понять как вести лог изменений если не могу понять что происходит в оси.
Вопросы:
1. Как получать сообщения о изменении и в файлах и в папках, размеры и т. д. сразу чтобы ChangeHandle менялся?
3. Есть какой нить список показывающий что вот число 1900 к примеру файл создался и так далее чтобы знать что показывать пользователю?

Цитата Neiron @ 15.02.11, 13:31

А проблема то что у меня все время ChangeHandle возвращает одно и тоже число и я просто не могу понять как вести лог изменений если не могу понять что происходит в оси.

ChangeHandle - это дескриптор события, которое ты инициализируешь в функции FindFirstChangeNotification. И он ничего не может ВОЗВРАЩАТЬ. А для того, чтобы понять, что у тебя произошло - создавай несколько событий, но С РАЗНЫМИ ФЛАГАМИ, а не с кучей флагов, объединенных or. Тогда сработает только то, чей флаг при открытии совпал с изменениями в системе. И в разных потоках, тогда потоки будут мирно "почивать" по:

WaitForSingleObject

, пока их не пнет система и "проснувшийся" поток сможет бодро "отрапортовать" основному:

Lines.Add

в процедуре синхронизации, перезапустить наблюдение:

FindNextChangeNotification

и "впасть в кому" до следующего события.

А почему тогда ChangeHandle мне пишет число, раз говорите что оно ничего невозвращает

MemoMonAktFileSys.Lines.Add(IntToStr(ChangeHandle) + ' Изменилось имя файла');

Я к стате не написал что ChangeHandle объявлен у меня глобально вот так:

ChangeHandle: THandle;

Написано, что Type Windows.THandle: cardinal - Windows.pas - следовательно возвращать может целочисленную переменную.

И разве это будет оптимально делать 5 потоков, чето мне кажется что тока процессор грузить таким методом будет?
На флаги:
FILE_NOTIFY_CHANGE_FILE_NAME;
FILE_NOTIFY_CHANGE_DIR_NAME;
FILE_NOTIFY_CHANGE_ATTRIBUTES;
FILE_NOTIFY_CHANGE_SIZE;
FILE_NOTIFY_CHANGE_LAST_WRITE.

Цитата Neiron @ 15.02.11, 15:58

А почему тогда ChangeHandle мне пишет число, раз говорите что оно ничего невозвращает

Еще раз.... В твоем коде ChangeHandle является ДЕСКРИПТОРОМ СОБЫТИЯ, которое было создано системой в несигнальном положении при вызове функции FindFirstChangeNotification. Дескрипторы в системе имеют тип cardinal и являются (как ни странно ) целыми неотрицательными числами, занимающими аж целых четыре байта (в 32 разрядных ОС). Что дескриптор МОЖЕТ ВОЗВРАЩАТЬ? Это функция?

Цитата Neiron @ 15.02.11, 15:58

И разве это будет оптимально делать 5 потоков, чето мне кажется что тока процессор грузить таким методом будет?

Тебе кажется или ты точно уверен? Я могу порекомендовать более подробно ознакомиться с функцией WaitForSingleObject и тогда все твои "страхи" развеются и ты станешь еще более "продвинутым" в понимании работы планировщика задач такой ОС, как Windows, и вопросы типа "процессор грузить" передвинутся (в этом случае) в разряд не самых волнующих.