Відсутня ініціація подій (у каталозі .git)

Я переглядаю файли для змін, використовуючи події inotify (як це трапляється, з Python, викликаючи libc).

Для деяких файлів під час a git cloneя бачу щось дивне: я бачу IN_CREATEподію, і я бачу, lsщо у файлі є вміст, однак я ніколи не бачу IN_MODIFYабо IN_CLOSE_WRITE. Це викликає у мене проблеми, оскільки я хотів би відповісти IN_CLOSE_WRITEна файли: зокрема, ініціювати завантаження вмісту файлу.

Файли, які дивно поводяться, знаходяться в .git/objects/packкаталозі, і вони закінчуються в .packабо .idx. Інші файли, які створює git, мають більш регулярний ланцюг IN_CREATE-> IN_MODIFY-> IN_CLOSE_WRITE(я не спостерігаю за IN_OPENподіями).

Це всередині докера на MacOS, але я бачив докази того ж на docker в Linux у віддаленій системі, тому моє підозра в аспекті MacOS не має значення. Я бачу це, якщо дивлюся і git cloneзнаходяться в одному докерному контейнері.

Мої запитання:

• Чому ці події відсутні у цих файлах?

• Що з цим можна зробити? Зокрема, як я можу відповісти на завершення запису до цих файлів? Примітка: в ідеалі я хотів би відповісти, коли написання "закінчено", щоб уникнути зайвого / (неправильного) завантаження "незакінченого" написання.

Редагувати: Читання https://developer.ibm.com/tutorials/l-inotify/ виглядає так, що те, що я бачу, відповідає

• окремий тимчасовий файл із ім'ям tmp_pack_hBV4Alz, яке створюється, змінюється та закривається;
• важко буде створена посилання на цей файл, з остаточним .packназвою;
• оригінальне tmp_pack_hBV4Alzім’я видалено.

Я думаю, що моя проблема, яка намагається використовувати inotify як тригер для завантаження файлів, потім зводиться до того, що помічає, що .packфайл є твердим посиланням на інший файл, і завантаження в цьому випадку?

Щоб відповісти на ваше питання окремо щодо git2.24.1 в Linux 4.19.95:

• Чому ці події відсутні у цих файлах?

Ви не бачите IN_MODIFY/ IN_CLOSE_WRITEподії, тому що git cloneзавжди будете намагатися використовувати жорсткі посилання для файлів під .git/objectsкаталогом. Під час клонування через мережу або через межі файлової системи ці події з’являться знову.

• Що з цим можна зробити? Зокрема, як я можу відповісти на завершення запису до цих файлів? Примітка: в ідеалі я хотів би відповісти, коли написання "закінчено", щоб уникнути зайвого / (неправильного) завантаження "незакінченого" написання.

Для того, щоб зафіксувати модифікацію жорстких посилань, вам потрібно встановити обробник для CREATEподії inotify, яка слідкує за цим посиланням і відслідковує їх. Зверніть увагу, що простий CREATEтакож може означати, що створений непорожній файл. Потім, у IN_MODIFY/ IN_CLOSE_WRITEдо будь-якого з файлів, ви повинні запустити однакову дію і на всіх пов'язаних файлах. Очевидно, що ви також повинні зняти ці відносини з DELETEподії.

Більш простим і надійним підходом було б, мабуть, періодично просто хешувати всі файли і перевіряти, чи змінився вміст файлу.

Корекція

Після уважної перевірки gitвихідного коду та роботи gitз ним straceя виявив, що gitвін використовує файли, відображені в пам'яті, але в основному для читання вмісту. Перегляньте, як використання xmmapзавжди викликається PROT_READлише. . Тому моя попередня відповідь нижче НЕ є правильною відповіддю. Тим не менш, з інформаційною метою я все одно хотів би зберігати його тут:

• Ви не бачите IN_MODIFYподій, оскільки packfile.cвикористовує mmapдля доступу до файлів і inotifyне повідомляє про модифікації mmapфайлів ed.

  З інотифікованої сторінки :

  API inotify не повідомляє про доступ та модифікації файлів, які можуть статися через mmap (2), msync (2) та munmap (2).

Я можу припустити, що Git більшість часу використовує оновлення атомних файлів, які робляться так:

1. Вміст файлу зачитується в пам'ять (і змінюється).
2. Змінений вміст записується в окремий файл (як правило, розташований у тому самому каталозі, що і оригінальний, і має рандомізоване ( mktemp-style) ім'я).
3. Потім новий файл буде rename(2)d -d над початковим; ця операція гарантує, що кожен спостерігач, який намагається відкрити файл, використовуючи його ім'я, отримає або старий вміст, або новий.

Такі оновлення розглядаються inotify(7)як moved_toподії - оскільки файл "з'являється" в каталозі.

Виходячи з цієї прийнятої відповіді, я припускаю, що може бути певна різниця в подіях на основі використовуваного протоколу (тобто ssh або https).

Чи спостерігаєте ви таку саму поведінку під час моніторингу клонування з локальної файлової системи за допомогою --no-hardlinksпараметра?

$ git clone git@github.com:user/repo.git
# set up watcher for new dir
$ git clone --no-hardlinks repo new-repo

Ваша спостережувана поведінка під час запуску експерименту як на Linux, так і на Mac хості, ймовірно, усуває цю відкриту проблему, яка є причиною https://github.com/docker/for-mac/isissue/896, але додає лише випадкові випадки.

Є ще одна можливість (від людини прищеплюють):

Зауважте, що черга подій може переповнюватися. У цьому випадку події втрачаються. Надійні програми повинні витончено обробляти можливість втрачених подій. Наприклад, може знадобитися перебудувати частину або весь кеш програми. (Один простий, але, можливо, дорогий підхід - закрити дескриптор файлу ініціювати, очистити кеш, створити новий дескриптор файлу ініціювати, а потім знову створити записи годинника та кеш-пам'яті для об'єктів, які слід контролювати.)

І поки git clone може генерувати важкі потоки подій, це може статися.

Як цього уникнути:

1. Збільшити буфер читання, спробуйте fcntl (F_SETPIPE_SZ) (такий підхід - здогадка, я ніколи не пробував).
2. Прочитайте події у великий буфер у виділеній темі, обробіть події в іншій потоці.

Можливо, ви зробили ту саму помилку, яку я зробив років тому. Я тільки два рази використовував inotify. Перший раз мій код просто спрацював. Пізніше я вже не мав цього джерела і почав знову, але цього разу я пропускав події і не знав чому.

Виявляється, коли я читав подію, я справді читав невеличку партію подій. Я розібрав очікуваного, подумавши, що це все, це все. Врешті-решт я виявив, що є більше отриманих даних, і коли я додав трохи коду для розбору всіх подій, отриманих від одного прочитаного, більше подій не втрачено.