test with bags made by bagger 2.8.1 fails to admit with the bag.txt file.

[zand...@gmail.com]

Hello everyone!

We faced a problem when transferring bags (bagIt) produced from Bagger v.2.8.1.

Context:

Archivematics 1.12.1

test with bags made by bagger 2.8.1 fails to admit with the bag.txt file.

We faced a problem when transferring bags (bagIt) produced from Bagger v.2.8.1.

According to RFC8493, the bag.txt file bag declaration must read:

2.1.1. Baggage declaration: bagit.txt

   The tag file "bagit.txt" MUST consist of exactly two lines in this order:

   BagIt-Version: MN

   Tag-File-Character-Encoding: ENCODING

RFC 8493 BagIt October 2018

   _M.N_ identifies the major (M) and minor (N) version numbers of BagIt.

   _ENCODING_ identifies the character set encoding used by the remaining tag files. _ENCODING_ MUST be "UTF-8", but backwards compatibility MAY be any other encoding registered in [-cs-record]. The baggage claim itself MUST be UTF-8 encoded and MUST NOT contain a Byte Order Mark (BOM) [ RFC3629 ].

   The number for this version of BagIt is "1.0".

Issue: Bagger v.2.8.1 (as well as bagIt.phyton, among others) works with the "0.97" version of bagIt and not the version recommended by RFC8493 (which recommends version "1.0"). Upon admission of our bagIt in Archivematica (transfer type: unzipped bag) the following failure is occurring:

Errors and diagnostics (stderr)

Error validating BagIt package: Expected bagit.txt does not exist: /var/archivematica/sharedDirectory/currentlyProcessing/sip_nobrade_bagger03-146b5196-c6f6-49fc-bf79-f7c2324db294/bagit.txt Failed bagit compliance. Not restructuring.

What can be done in this case? Is there really an incompatibility between the version of bagIt worked by Bagger v.2.8.1 with the version recommended ("1.0") by RFC8493 that can cause this invalidation of the bag.txt file on admission by Archivematica?

Thanks!