Здравствуйте, Mazay, Вы писали:

M>У меня этот код за раз читает несколько событий. Для теста я удаляю несколько папок в отслеживаемой папке командой rm -r /tmp/test/*. И мне в одном read приходят сразу несколько событий.
M>Может у тебя события слишком медленно происходят, так что read успевает вызваться несколько раз? Попробуй паузу по-больше поставить.
Я имею ввиду немного другое. Данный код и куча других примеров которые нагуглил и попробовал работают именно так как написано выше.
Не имеет значения как часто происходят события. Код выше расчитан чтобы вычитывать сколько угодно большой read, все сначала быстро складывается в буфер послче чего буфер обрабатывается. Вопрос совсем в другом. Меня крайне удивляет следующее. Допустим я наблюдаю некоторое возможно длительное время за каталогом и тут внезапно решил сделать read. Вместо того чтобы получить по одному inotify_event для каждого каким либо образом измененного файла с битовой маской всех событий (согласно как написано в мане)

mask contains bits that describe the event that occurred (see below).

я получаю каждый event отдельно. И это однозначно не связано с тем что события происходят медленно. Все они получены именно в одном единственном read. Но почемуто даже для одного и того же файла каждое событие отдельно.

Пример:
1. Добавляем наблюдение для каталога /home/sba/projects/temp
2. Открываем и сохраняем в kate файл example.txt
3. Ждем 10 сек и только после этого делаем один read

16:41:08 DEBUG [src/CDirMonitor.cpp:58 - Process] 1024
Как и ожидалось все пришло одним read, один блок длиной 1024 байта
                                                  Каталог                   Файл        Маска  cookie
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 32 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 1 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 16 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 32 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 1 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 16 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 32 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 1 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 16 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 32 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 1 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 16 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt~ | 512 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 32 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | qt_temp.C15277 | 256 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | qt_temp.C15277 | 32 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 1 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | qt_temp.C15277 | 2 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | qt_temp.C15277 | 8 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | qt_temp.C15277 | 64 | 2325
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt~ | 128 | 2325
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt~ | 4 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 16 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 2 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 32 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 2 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 8 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 32 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 16 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 32 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 1 | 0
16:41:08 DEBUG [src/CDirMonitor.cpp:72 - Process] /home/sba/projects/temp | example.txt | 16 | 0

Как видно маска вовсе не contains bits а contains bit.

Для себя хочу понять, действительно ли это нормальное поведение inotify.
И отсюда вопрос, для определения устаревания файлов, таких как удаление, изменение (нужно для кешера) придется поверх inotify сооружать еще контейнер который бы группировал однотипные события в одну записть, чтобы не вызывать лишний раз обработчик события. На примере предоставленом выше пользователь только один раз сохранил файл, значит внутренности поменялись только один раз, и по логике надо только один раз вызвать обработчик который удалит файл из кеша, но inotify уперто подсказывает что IN_MODIFY аж 2 раза. Ладно это неприциппиально, привяжемся только к IN_CLOSE_WRITE который действительно показывается только 1 раз. Но если б надо было цеплять обработчик на любой другой event, то получилась бы каша из ненужный вызовов.