Został zaprezentowany projekt rars, rozwijający swobodną implementację narzędzia dla formatu RAR, napisaną w języku Rust, która wspiera nie tylko dekompresję, ale również tworzenie archiwów RAR. Narzędzie obsługuje zarówno wczesne formaty RAR 1.3/1.4 z sygnaturą „RE~^”, jak i najnowszą wersję RAR 7. Dostępne są rozszerzone operacje, takie jak podział na woluminy, ochrona hasłem, szyfrowanie nagłówków, dołączanie komentarzy, filtry RARVM, indeksy do szybkiego otwierania oraz mechanizmy odzyskiwania uszkodzonych danych. Kod jest dystrybuowany na zasadach licencji MIT i Apache-2.0. Na bazie biblioteki PyO3 przygotowane zostały opakowania dla języka Python, które implementują API w stylu rarfile do przeglądania, testowania i wydobywania archiwów, jak również API w stylu RarBuilder do tworzenia lub rekonstrukcji archiwów.
Cechą projektu jest to, że realizuje pracę z formatem RAR bez korzystania z kodu narzędzia unrar, które jest dystrybuowane na zasadach niewolnych licencji, zabraniającej używania kodu unrar do odtworzenia algorytmu kompresji RAR lub opracowania zgodnego z RAR archiwizatora. Z powodu tego ograniczenia większość wolnych archiwizatorów ograniczała się jedynie do funkcji dekompresji plików RAR, a do tworzenia archiwów RAR konieczne było korzystanie z własnościowego narzędzia od RARLAB.
Osobno utworzono repozytorium rar-research, w którym opublikowano specyfikacje dla formatów RAR 1.3/1.4, RAR 1.5-4.x i RAR 5.0/7.0, a także notatki dotyczące używanych algorytmów, filtrów, metod weryfikacji i przywracania integralności, szyfrowania, podziału na woluminy oraz mechanizmów ochrony. Ponieważ w momencie tworzenia projektu rars nie istniała oficjalna pełna specyfikacja, dokumentacja została odtworzona na podstawie kodu dekompresorów, starych implementacji, testowych archiwów oraz analizy binarnych wersji RAR dla DOS i Windows.
Implementacja została stworzona z użyciem narzędzi AI OpenAI Codex 5.5 i Claude Opus 4.7 w wolnym czasie pracy, w ciągu około pięciu tygodni. Na pierwszym etapie modele były stosowane do systematyzacji informacji o formacie oraz uzupełniania luk w opisie, po czym na podstawie odtworzonej specyfikacji wygenerowano kod w języku Rust. Do clarifikacji specyfikacji i udoskonalenia realizacji zastosowano testowanie na rzeczywistych archiwach i porównanie z wzorcowymi implementacjami.
Zauważono, że narzędzia AI dobrze radziły sobie z przekształceniem formalnych opisów w kod oraz z rutynową realizacją dużej ilości funkcji, ale nie były w stanie zapewnić kontroli architektonicznej. Bez ścisłego nadzoru modele AI były skłonne do omijania testów, komplikowania kodu i pomijania oczywistych problemów, które wpływały na użyteczność. Zdaniem autora, w projekcie tej skali testy, dokumentacja i komentarze stały się nie tylko narzędziami weryfikacyjnymi, ale także sposobem kierowania generowaniem kodu w odpowiednią stronę.
Przyspieszenie prac rozwojowych stało się możliwe po wprowadzeniu w OpenAI Codex trybu „/goal”, który pozwalał agentowi AI przez długi czas pracować nad jednym zadaniem, kompresując kontekst i kontynuując po jego przepełnieniu. W tym trybie Codex kilka razy działał ponad 6 godzin, a raz około 16 godzin, realizując znaczną część pozostałej funkcjonalności, taką jak przywracanie danych, szyfrowanie i archiwa wielotomowe. Biorąc pod uwagę znaczną dotację na tokeny, wydano 40 funtów.
Pod względem poziomu kompresji rars średnio odstaje o 5-10% od WinRAR. Pod względem prędkości kompresji i dekompresji rars jest znacznie wolniejszy niż WinRAR z powodu braku pełnowartościowych optymalizacji. W projekcie istnieje już tryb „—features fast”, który stosuje optymalizacje oparte na instrukcjach SIMD w celu przyspieszenia kompresji i dekompresji, ale oparty na eksperymentalnym API std::simd, dostępnym tylko w testowych wersjach narzędzia Rust. Zrealizowano również tryb „—features parallel”, wykorzystujący bibliotekę Rayon do równoległego kompresowania pojedynczych plików.
Jewgienij Roshal, twórca RAR, skomentował wykorzystanie inżynierii wstecznej starych plików binarnych RAR podczas opracowywania rars, co jest zabronione umową licencyjną. Według Jewgienija, na razie nie wie, co z tym zrobić, i zamierza poczekać na opinię firmy win.rar GmbH.
Źródło: opennet.ru
