Z dziennika architekta: fileinfo, indexer i LLM

Tym razem zmienimy tematykę, chociaż nadal będzie powiązana pośrednio z cyberbezpieczeństwem. Robiąc ostatnio poprawki składające się na wersje między 4.136 a 4.163 zaimplementowałem z pomocą modelu LLM (ponownie) mechanizm weryfikacji plików uploadowanych na serwer w oparciu o fileinfo (UNIX binary). O ile upload zadziałał, o tyle nie przewidziałem, że podjęcie decyzji, by przerobić też worker pracujący jako indekser. Ten worker odpowiada głównie za tworzenie indeksu plików i podział ich na kategorie zgodnie z przyjętymi z góry założeniami. Założenie jest takie, że przede wszystkim rozszerzenie i MIME muszą być zgodne z konfiguracją systemu, a jeśli są to MIME musi pasować do jednej z ustawionych kategorii (jeśli nie rozpoznajemy MIME, kategoryzujemy to jako application/octet-stream). Wszystko brzmi dobrze. Tylko, że jak to zwykle bywa w takich przypadkach, nic nie było dobrze i trzeba było dużo debugować.

Jak to działało, a jak miało działać?

Oryginalnie mechanizm był uproszczony. Wynikało to z tego, że (co już teraz pamiętam) system nie funkcjonował dokładnie tak jak chciałem. Niektóre pliki trafiały do kategorii, do których nie należały, albo nie pokazywały się wcale. Wynikało to z tego, że oryginalnie system nie posiadał kategorii “Różne”. W tym momencie posiada ją, więc wszystkie pliki, co by się nie stało są dostępne, po prostu w kategorii do której należą lub w “Różne”. Do wersji 4.136 mechanizm używał biblioteki Winista.Mime, która nie analizuje magic numbers, a wyłącznie rozszerzenie. Przy takim założeniu oczywiście nie ma specjalnego problemu, bo jeśli mamy rozszerzenie, a Winista zwraca standardowy MIME, a nie “rozszerzony” lub specjalny to matching działa 1 do 1 poprawnie. Problem pojawia się teraz, gdzie używamy fileinfo, który zwraca stosunkowo dokładnie czym dany plik jest, a więc jeśli nie mamy mapy aliasów (u mnie jest, ale bardzo prosta), a samo rozszerzenie jest tylko pomocniczne i to głownie przy wykryciu typu MIME i tego czy jest dozwolony, a nie tego do której kategorii pasuje. Same kategorie mają wyłącznie przypisane listy MIME. Stąd, jeśli z jakiegoś powodu fileinfo uzna, że np. pliki .mkv to application/octet-stream lub użyje aliasu, którego mój system “nie zna”, trafiamy do kategorii “Różne” zamiast “Materiały Wideo”. To hipotetyczne, bo akurat faktycznie .mkv trafiło do “Różne”, ale nie wynika to z błędu fileinfo, a bardziej tego, że prawdopodobnie niegdyś system został zaindeksowany z błędnym MIMEem i nawet przy migracji z MinIO do Garage został przniesiony. Na ten moment pliki .mkv mogą pozostać w starej kategorii, ale będę musiał do dalej debugować. A jak to miało działać? No, dokładnie tak, jak do tej pory. Po prostu nie uwzględniłem kompletnie tego, że po zmianie sposobu i silnika analizy plików dojdzie do takiej zmiany.

A co ma do tego LLM?

Bardzo dobre pytanie. LLM był wyłącznym wykonawcą kodu, ale zamysł i projekt należą do mnie. Używałem za równo modeli Claude Opus 4.6 jak i GPT5.4 w ramach Copilota na cloudzie (GitHub Cloud). Robiłem to jak zawsze iteracyjnie, rozpisując cały kontekst, a Copilot miał tam do dyspozycji MCP pozwalające na lint, compile, przeszukiwanie repo itd. I winę za serię debugowania i problemów ponoszę… ja. Mój oryginalny zamysł był dobry, ale nie uwzględniłem tego, jak dokładnie działa indekser i dlaczego może to zmienić całkowicie działanie core’owego mechanizmu systemu. Dlaczego nie krzyczę, że Opus nie ogarnął czy GPT też zły i niedobry, ale na pewno Opus 4.8 by dał radę? Bo wiem, że tak, jak ja promptowałem, czyli bardzo autorytatywnie, w formie nakazu model nie sprzeciwi się, a wyłącznie zasugeruje delikatne korekty. Nawet, jeśli będzie robił coś bzdurnego, nie wychwyci tego, bo nie kazałem mu analizować, kazałem mu zrobić. I też tak było. Zrobił dokładnie to, co miał zrobić. I to jest moje podejście do użytkowania LLM, że co by nie było - odpowiedzialność ponoszę ja, a nie model.

Co dalej?

Na ten moment zostaje tak, jak jest, bo za równo pliki notatek są w “Różne”, jak i pliki matroska. Te ostatnie są mniej istotne dla mnie, a pliki notatek (.pcn) miały dokładnie tam trafić. Docelowo chcę, aby .mkv też były w Materiały Wideo, a same notatki powinny trafiać ostatecznie do przeznaczonej dla nich kategorii: Notatki. Na ten moment domyślnie trafiają do tagu “notes” w “Różne”, potem będą trafiały do odrębnej kategorii co pozwoli tworzyć tagowanie notatek od strony DMS (PikaCore). Reszta funkcjonalności jest tak, jak była, nic się nie zmieniło. Swoją drogą, takie informacje - o zmianach, zakończenie outtage’u czy przerwy technicznej - ogłaszam na tzw. Cloudfront. Dokładniej to na podstronie status. Przykładowo informacja o aktualnym “przeniesieniu niektórych plików” do innych kategorii jest w najnowszym wpisie na podstronie systemu PikaCore