Closed kerschfilip closed 3 years ago
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 .
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.
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.
@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.
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
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.
Děkuji, také jsem to vyzkoušel a potvrzuji, že je to vyřešené
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