LIBCAS / ARCLib

ARCLib – komplexní řešení pro dlouhodobou archivaci digitálních (knihovních) sbírek
GNU General Public License v3.0
4 stars 1 forks source link

Absolutní / a relativní ./ cesty v filesec #77

Closed godnat closed 3 years ago

godnat commented 4 years ago

Nedaří se mi vložit SIP balíčky, které by dle mého názoru měly bez problému projít. Arclib hlásí "No value present"

image

Porovnala jsem balíček, který neprošel s touto hláškou a balíček, který prošel bez problému a nejsou v nich významné rozdíly. Je možné zjistit proč balíčky neprochází a upravit hlášku, místo "No value present" na něco konkrétnějšího?

Na No value present neprošly tyto: ARCLIB_000000924 ARCLIB_000000905

a další.

Zkousela jsem i "vypnout" cast kroku v SIP profilu, aby byly pozadavky na balicky co nejmensi, ale stale neprochazi na No value present.

godnat commented 4 years ago

Zdá se, že problém bude (alespon pro některé balíčky) v hlavním mets souboru v sekci , kde v mets:fileGrp/mets:file/mets:Flocat je odkaz na soubor zapsán _./mastercopy/mc_xbs008-00043a0083.jp2, vadí tam tečka a lomítko na začátku, když jsme to v balíčcích opravili na: mastercopy/mc_xbs008-00043a0083.jp2, balíčky prošly. Je možné nastavit aby Arclib umět pracovat i se zápisy cest ./mastercopy/mc_xbs008-00043a0083.jp2 a _/mastercopy/mc_xbs008-00043a0083.jp2? Možná to jde nějak zapsat v SIP profilech, ae netuším jak.

yantom commented 4 years ago

Děkujeme za detailní popis issue. V SIP profilu se toto nastavit nedá, jednalo se o nedostatek aplikace. Podpora byla doimplementována a nasazena. Vybrali jsme balíček z předchozího ingestu _ARCLIB000000924 a úspěšně prošel v novém ingestu _ARCLIB000001020

godnat commented 4 years ago

Otestováno, prošly balíčky jež měly cestu uvedenou ./amdsec i /amdsec. Díky.

yantom commented 4 years ago

Pro jistotu otvírám ještě jednou s komentářem.

U relativních cest (začínajících ./) je současná implementace určitě vyhovující. Problém může nastat u absolutních cest (začínajících /) v případě že se jedná o NDK zabalený v PROARC.

Absolutní cesty chápeme klasicky jako "cesty od počátku" kde jako počátek bereme kořen balíčku. Při zabalení NDK do PROARC se však kořen mění, a cesty které byly v původním NDK METS zadány absolutně pravděpodobně přestanou fungovat (předpokládám že cesty při vkládání do PROARC neupravujete). Bylo by dobré toto zkontrolovat.

kerschfilip commented 4 years ago

Nejsem si jistý, co přesně má být zkontrolováno, můžete mne, prosím, navést?

cesty v NDK mets*.xml jsou v našich archivních balíčcích zapsány například následovně: amdsec/amd_mets_aba007-0000cf_0007.xml - je to tak proto, že NDK složku v archivním balíčku z ProArcu má být možné "vyndat" a použít jako samostatný NDK balíček. Pro mets v NDK složce je tak za kořenovou považována právě NDK složka

Vzhledem k tomu, že celé archivní balíčky jsou zabaleny do bagitu, předpokládám ale že pro kontrolu fixity a tvorbu fileSec je používán soubor manifest-md5.txt a ne mets z NDK složky. Alespoň jsem se nesetkal zatím s žádnou chybou při zpracování balíčku. fileSec v ARCLib AIP XML se také zdá být v pořádku. Cesty jsou zapsány například takto: data/NDK/aba007-0000cg/amdsec/amd_mets_aba007-0000cg_0025.xml

yantom commented 4 years ago

Z popisu @godnat jsem pochopil že v nativním NDK balíčku může být cesta uvedena třemi způsoby:

1) amdsec/amd_mets_aba007-0000cf_0007.xml 2) ./amdsec/amd_mets_aba007-0000cf_0007.xml 3) /amdsec/amd_mets_aba007-0000cf_0007.xml

První dva případy jsou OK ale třetí bude pravděpodobně způsobovat problém. Jako nejsprávnější řešení se mi jeví takto zapsanou cestu přepsat na formát 1. či 2. příkladu ještě před zasláním do ARCLib.

yantom commented 3 years ago

Vzpomenuto na meetingu. Případů kdy jsou cesty zapsány třetím způsobem by mělo být minimum. V případě že se objeví, je řešením úprava vstupního balíčku. Prozatím tedy zavírám, pokud by zde bylo co k řešení prosím o znovuotevření.