Brakujące zdarzenia inotify (w katalogu .git)

Oglądam pliki pod kątem zmian za pomocą zdarzeń inotify (jak to się dzieje, z Pythona, wywołującego libc).

W przypadku niektórych plików podczas a git clonewidzę coś dziwnego: widzę IN_CREATEzdarzenie i widzę, lsże plik ma treść, jednak nigdy nie widzę IN_MODIFYani IN_CLOSE_WRITE. Powoduje to problemy, ponieważ chciałbym odpowiedzieć IN_CLOSE_WRITEna pliki, a konkretnie zainicjować przesyłanie zawartości pliku.

Pliki, które zachowują się dziwnie, znajdują się w .git/objects/packkatalogu i kończą się na .packlub .idx. Inne pliki, które tworzy git, mają bardziej regularny IN_CREATE-> IN_MODIFY-> IN_CLOSE_WRITEłańcuch (nie szukam IN_OPENwydarzeń).

Jest to wewnątrz okna dokowanego w systemie MacOS, ale widziałem dowody tego samego w oknie dokowanym w systemie Linux w zdalnym systemie, więc moje podejrzenie, że aspekt MacOS nie jest istotny. Widzę to, jeśli oglądam i git clonesą w tym samym kontenerze dokera.

Moje pytania:

• Dlaczego w tych plikach brakuje tych zdarzeń?

• Co można z tym zrobić? W szczególności, jak mogę zareagować na zakończenie zapisu do tych plików? Uwaga: idealnie chciałbym odpowiedzieć, gdy pisanie jest „zakończone”, aby uniknąć niepotrzebnego / (niepoprawnego) przesyłania „niedokończonego” pisania.

Edycja: Czytanie https://developer.ibm.com/tutorials/l-inotify/ wygląda na to, że to, co widzę, jest zgodne z

• oddzielny plik tymczasowy o nazwie podobnej tmp_pack_hBV4Alz, tworzony, modyfikowany i zamykany;
• trudny związek jest tworzony do tego pliku, o ostatecznej .packnazwie;
• pierwotna tmp_pack_hBV4Alznazwa zostanie usunięta.

Wydaje mi się, że mój problem polega na tym, że próbuję użyć inotify jako wyzwalacza do przesyłania plików, a następnie sprowadza się do zauważenia, że .packplik jest twardym linkiem do innego pliku, i przesłanie w tym przypadku?

Aby odpowiedzieć na pytanie osobno dla git2.24.1 w Linuksie 4.19.95:

• Dlaczego w tych plikach brakuje tych zdarzeń?

Nie widzisz IN_MODIFY/ IN_CLOSE_WRITEevents, ponieważ git clonezawsze będzie próbował użyć twardych linków do plików w .git/objectskatalogu. Podczas klonowania przez sieć lub przez granice systemu plików zdarzenia te pojawią się ponownie.

• Co można z tym zrobić? W szczególności, jak mogę zareagować na zakończenie zapisu do tych plików? Uwaga: idealnie chciałbym odpowiedzieć, gdy pisanie jest „zakończone”, aby uniknąć niepotrzebnego / (niepoprawnego) przesyłania „niedokończonego” pisania.

Aby złapać modyfikację twardych linków, musisz skonfigurować moduł obsługi CREATEzdarzenia inotify , które następuje i śledzi te linki. Pamiętaj, że prosty CREATEmoże również oznaczać, że utworzono niepusty plik. Następnie na IN_MODIFY/ IN_CLOSE_WRITEdo dowolnego pliku musisz również wywołać tę samą akcję na wszystkich połączonych plikach. Oczywiście musisz również usunąć tę relację z DELETEwydarzenia.

Prostszym i bardziej niezawodnym podejściem byłoby prawdopodobnie okresowe mieszanie wszystkich plików i sprawdzanie, czy zawartość pliku się zmieniła.

Korekta

Po dokładnym sprawdzeniu gitkodu źródłowego i uruchomieniu gitz nim stracezauważyłem, że gitużywa plików odwzorowanych w pamięci, ale głównie do odczytu zawartości. Zobacz, którego użycie xmmapjest zawsze wywoływane PROT_READtylko z . . Dlatego moja poprzednia odpowiedź poniżej NIE jest poprawną odpowiedzią. Niemniej jednak w celach informacyjnych chciałbym zachować to tutaj:

• Nie widzisz IN_MODIFYzdarzeń, ponieważ packfile.cużywa mmapdostępu do plików i inotifynie zgłasza zmian dla mmapplików ed.

  Z strony inotify :

  Interfejs API inotify nie zgłasza dostępu do plików i modyfikacji, które mogą wystąpić z powodu mmap (2), msync (2) i munmap (2).

Mogę spekulować, że Git przez większość czasu używa aktualizacji plików atomowych , które są wykonywane w następujący sposób:

1. Zawartość pliku jest wczytywana do pamięci (i modyfikowana).
2. Zmodyfikowana zawartość jest zapisywana w osobnym pliku (zwykle znajdującym się w tym samym katalogu co oryginalny) i posiadającym losową ( mktemp-stylową) nazwę.
3. Nowy plik jest następnie rename(2)d -d nad oryginalnym; ta operacja gwarantuje, że każdy obserwator próbujący otworzyć plik przy użyciu jego nazwy otrzyma starą lub nową zawartość.

Takie aktualizacje są postrzegane inotify(7)jako moved_tozdarzenia - ponieważ plik „pojawia się ponownie” w katalogu.

Na podstawie tej zaakceptowanej odpowiedzi zakładam, że mogą istnieć pewne różnice w zdarzeniach w zależności od używanego protokołu (tj. Ssh lub https).

Czy obserwujesz to samo zachowanie podczas monitorowania klonowania z lokalnego systemu plików z --no-hardlinksopcją?

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

Twoje zaobserwowane zachowanie podczas uruchamiania eksperymentu zarówno na hoście Linux, jak i Mac prawdopodobnie eliminuje ten otwarty problem, który jest przyczyną https://github.com/docker/for-mac/issues/896, ale dodaje się tylko incase.

Istnieje inna możliwość (od man inotify):

Pamiętaj, że kolejka zdarzeń może się przepełnić. W takim przypadku zdarzenia są tracone. Solidne aplikacje powinny z wdzięcznością poradzić sobie z możliwością utraty zdarzeń. Na przykład może być konieczne przebudowanie części lub całości pamięci podręcznej aplikacji. (Jednym prostym, ale być może drogim podejściem jest zamknięcie deskryptora pliku inotify, opróżnienie pamięci podręcznej, utworzenie nowego deskryptora pliku inotify, a następnie ponowne utworzenie zegarków i wpisów w pamięci podręcznej dla monitorowanych obiektów.)

I chociaż git clonemoże generować duży przepływ zdarzeń, może się to zdarzyć.

Jak tego uniknąć:

1. Zwiększ bufor odczytu, spróbuj fcntl (F_SETPIPE_SZ) (takie podejście jest przypuszczeniem, nigdy nie próbowałem).
2. Odczytuj zdarzenia do dużego bufora w dedykowanym wątku, przetwarzaj zdarzenia w innym wątku.

Może popełniłeś ten sam błąd, który popełniłem lata temu. Użyłem inotify tylko dwa razy. Za pierwszym razem mój kod po prostu zadziałał. Później nie miałem już tego źródła i zacząłem od nowa, ale tym razem brakowało mi wydarzeń i nie wiedziałem, dlaczego.

Okazuje się, że kiedy czytałem jakieś wydarzenie, naprawdę czytałem małą porcję wydarzeń. Analizowałem ten, którego się spodziewałem, myśląc, że to było to wszystko. W końcu odkryłem, że jest więcej w otrzymywanych danych, a kiedy dodałem mały kod do parsowania wszystkich zdarzeń otrzymanych z jednego odczytu, nie było więcej zdarzeń utraconych.