Fixity Check hlásí Missing File i když soubor nechybí

[kerschfilip]

Několik mých posledních ingestů (například tady) skočilo chybou při proceduře fixity check:
_missing file: data/Original_TifLZW/ABA007260088086080001.tif. used config: false at: /fixityCheck/0/continueOnMissingFiles [...]

Zdá se, že ARCLib hlásí, že chybí veškeré soubory, které popisuje md5 v balíčku. Soubory tam přitom ale jsou, dokonce je předtím Droid správně identifikuje.

Nejsem si jistý, kde je problém. Některé z vyzkoušených balíčků v minulosti určitě procházeli v pořádku, nevím jestli se tedy nejedná o chybu v ARCLibu. Děkuji za radu

[yantom]

Toto bude předpokládám novou implementací checkeru. Viz. dokumentace, Ingest - The Archival Proces, fixity checker.

Bylo požadováno aby kromě souborů odkazovaných z mets kontroloval i jakýkoliv soubor s příponou .md5, sha512 apod., předpokládám, že se nějaký takový nachází ve vstupním balíčku. Otázkou je proč tento selhává. Tipl bych si že v souboru s checksumy je uvedena absolutní cesta, ale samotný soubor se z hlediska kořene balíčku nenachází na původním místě, neboť byl, stejně jako ostatní soubory SIP někam zanořen. Ověříme stav.

On Fri, Dec 18, 2020, 16:44 kerschfilip notifications@github.com wrote:

Několik mých posledních ingestů (například tady https://arclib-test.lib.cas.cz/ingest-workflows/ARCLIB_000003232) skočilo chybou při proceduře fixity check: missing file: data/Original_Tif_LZW/ABA007260088086080001.tif. used config: false at: /fixityCheck/0/continueOnMissingFiles [...]

Zdá se, že ARCLib hlásí, že chybí veškeré soubory, které popisuje md5 v balíčku. Soubory tam přitom ale jsou, dokonce je předtím Droid správně identifikuje.

Nejsem si jistý, kde je problém. Některé z vyzkoušených balíčků v minulosti určitě procházeli v pořádku, nevím jestli se tedy nejedná o chybu v ARCLibu. Děkuji za radu

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LIBCAS/ARCLib/issues/124, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWZ6NBMISDHZA6QW7HHXMLSVN2FHANCNFSM4VBK4EEQ .

[yantom]

Oprava nasazena. Problém byl jinde. Nicméně soubor Original_Tif_LZW/ABA007260088086080001.tif v odkazovaném SIP skutečně chybí. Ostatní zde ale jsou.

[jbil7]

Omlouvám se, že do tohoto vstupuji a celou věc tím ještě komplikuji. Všiml jsem si však zde, že po některém z posledních nasazení neprochází fixity checkerem ani formát, který je specifikován pro .md5 soubory v NDK balíčcích, viz Definice metadatových formátů NK, bod 5.8 (dále DMF).

Jak jsem zjistil, neprochází formát s absolutní cestou, který by dle DMF měl procházet:

07e7f4cceb5b3c3399fe2bc454118157 \txt\txt_abe343-000dwc_0001.txt

Zkoušel jsem otočit lomítka (dle DMF jsou tolerovány obě možnosti \ i /) a dospěl jsem k témuž výsledku.

Ačkoliv je v DMF stanoveno, že "produkce pravidla tvoří jméno souboru ve formě aboslutní cesty v hierarchické struktuře balíku SIP" a že "cesta je absolutní vůči kořenové složce SIP balíčku", zkoušel jsem i ingesty bez root lomítka na počátku cesty. Za mezeru mezi md5 hodnotou jsem zkusil dosadit jak klasickou mezeru \s, tak i TAB \t (obojí je dle DMF tolerovatelné). S užitím TABu jsem tedy dospěl k tomuto formátu: 07e7f4cceb5b3c3399fe2bc454118157 txt/txt_abe343-000dwc_0001.txt. Zde prošla většina souborů, kromě prvního uvedeného souboru v seznamu .md5 souboru, u něhož byl zahlášen FileNotFoundException:

java.io.FileNotFoundException: /opt/arclib/workspace/ARCLIB_000003241/abe343-000dwc/xt/txt_abe343-000dwc_0001.txt (No such file or directory)

Pravděpodobnou příčinou zde může být vynechání prvního písmena ze zadané cesty (xt místo txt).

V minulosti jsem se v .md5 souborech NDK balíčků od některých producentů setkal i s relativními cestami (začínajícími buď ./ anebo názvem adresáře bez úvodního lomítka). Asi by bylo vhodné, kdyby takové případy procházely, ale systém na toto upozorňoval. Nicméně md5 soubory s absolutními cestami by dle DMF měly procházet.

[yantom]

@jbil7 Implementace vycházela ze specifikace https://en.wikipedia.org/wiki/Md5sum kde jsou mezi checksumem a cestou přesně 2 znaky. Předpokládám že v některých balících jste vložil pouze jeden bílý znak a proto Vám následně ořezal první znak z cesty. Některé popsané formáty by systém v původní implementaci určitě nezpracoval. Na serveru je již nasazena nová implementace ve které již není kontrola .md5 souborů prováděna defaultně a je třeba ji nastavit v JSON konfiguraci (viz https://github.com/LIBCAS/ARCLib/wiki/ingest-workflow#fixity-checker , konfiguraci jsem rovnou doplnil do Vašeho profilu: https://arclib-test.lib.cas.cz/producer-profiles/1cb8d130-52f9-11ea-a3a8-319cecea4518). Provedl jsem testovací ingest jednoho z Vašich balíku (https://arclib-test.lib.cas.cz/ingest-batches/bbca8bd9-c063-4b6b-8b69-5ccde1242da9) a již prochází, interně máme napsané testy i na další popsane use-cases. Nový regex (\w+)[*\s]+(\S+) umožňuje checksum od cesty oddělit kombinací 1-n bílých znaků. Cesta je chápána absolutně pokud začíná lomítkem (dopředné i obrácené), pokud však systém na této cestě soubor nenajde, pokusí se ji ještě interpretovat jako relativní. Cesta může také začínat bez lomítka nebo tečkou, v tom případě je brána jako relativní rovnou.

V nové implementaci je také možné 3 dostupné metody fixity checkeru kombinovat, tedy pokud to SIP formát umožňuje lze zkontrolovat METS odkazovaný ze SIP profilu, BAGIT manifest soubory i všechny ostatní .md5 soubory. Navíc je upravena chybová hláška která nyní uvádí soubor z něhož jsou chybějící/nevalidní checksumy odkazovány, např. File: manifest-md5.txt references missing file: data/Original_Tif_LZW/ABA007260088086080001.tif. missing config at: /fixityCheck/0/continueOnMissingFiles

@kerschfilip I Vám jsem do profilu https://arclib-test.lib.cas.cz/producer-profiles/c02a4de0-4127-11eb-bd2a-afbc023eb402 vložil novou konfiguraci. Další Vaše profily jsem neupravoval, bude potřeba jim nastavit zda jsou BAGIT či METS či obojí. COMMON by Vám snad měl také fungovat všude.

[kerschfilip]

Vyzkoušeno, zdá se, že funguje správně, jen pokud je odhalen chybějící soubor (ať už metodou BAGIT nebo COMMON) vzniká incident (například zde: https://arclib-test.lib.cas.cz/ingest-batches/012e681b-eb00-40f0-b446-bcec94d83bef). Domnívám se, že by to tak být nemělo - pokud specifikuji ve workflow konfiguraci "continueOnMissingFiles": false, pak bych očekával že ingest workflow automaticky selže. Navíc zpráva incidentu je poměrně nepřesná:

couldn't execute activity <serviceTask id="fixityCheck" ...>: ARCLib incident: Ingest workflow internal runtime exception: java.lang.StringIndexOutOfBoundsException: begin 0, end 3500, length 303

[yantom]

Chyba byla v kódu který ukončuje neúspěšný ingest, vzniklý incident se tedy nevázal k samotnému chybějícímu souboru ale k této chybě. Oprava nasazena na server. U zmíněného ingestu jsem vyřešil incident a ingest okamžitě selhal s požadovanou hláškou.

[kerschfilip]

Děkuji, také jsem to vyzkoušel a potvrzuji, že je to vyřešené