DROID doesn't honour offsets defined for variable position byte sequences in PRONOM

An issue discovered through a similar bug in my skeleton test suite generator is that DROID doesn’t honour offsets defined for variable sequences in PRONOM. The skeleton suite bug is here: https://github.com/exponential-decay/skeleton-test-suite-generator/issues/2

Take SIARD as the example, and the example skeleton file below:

50 4B 03 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 6D 6C 6E 73 3D 22 68 74 74 70 3A 2F 2F 77 77 77 2E 62 61 72 2E 61 64 6D 69 6E 2E 63 68 2F 78 6D 6C 6E 73 2F 73 69 61 72 64 2F 31 2E 30 2F 6D 65 74 61 64 61 74 61 2E 78 73 64 22 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50 4B 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50 4B 05 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The sequences defined are as follows:

Position type    Absolute from BOF
Offset   0
Value    504B0304

Position type    Absolute from EOF
Offset   0
Value    504B01{43-65531}504B0506{18-65531}

Position type    Variable
Offset   1024
Value    786D6C6E733D22687474703A2F2F7777772E6261722E61646D696E2E63682F786D6C6E732F73696172642F312E302F6D657461646174612E78736422

As the variable sequence is only 14 bytes into the sample file it shouldn’t match in DROID as the definition places it, at least, 1024 bytes in. However, it does.

I haven’t isolated any other files to test this with, however, I expect the behaviour to be the same.

Tested with DROID 6.1.3 on Ubuntu Linux.

[Dclipsham]

I either merged bof/var sequences or removed unnecessary var offsets as of 31/03/14 v74 signature update.

[Dclipsham]

No problem Ross, We ran a slightly different query, where we were seeking values of offsets that were !NULL, which gives us fmt/354 (and this was introduced in v73), and fmt/596 too, although the offset value of both is set to zero, so otherwise our lists tally.

The suggestion of additional unit testing sounds very good.

I should be able to investigate the behaviour more thoroughly over the next day or two, and will update.

David