Ensure support for uncompressed ARC files

[anjackson]

Following this report on the mailing list, it seems OpenWayback does not cope with uncompressed ARC files at present.

Therefore, we need another unit test like this one (in iipc/webarchive-commons):

https://github.com/iipc/webarchive-commons/blob/master/src/test/java/org/archive/io/warc/WARCReaderFactoryTest.java

...but for ARCs.

[egh]

I added a test for this in a local branch, and it seems to work fine out of the box. I'm not sure what the issue is.

[egh]

Was able to duplicate error using the blackbox example ARC, uncompressed, with the default WAR build. Let me see if I can write a test.

[egh]

Iterating over uncompressed arcs work. It's probably something to do with seeking.

[csrster]

I have a possible fix based on a change in ResourceFactory.getResource() . Should I contribute it through the fork/branch/pull-request process ?

You can reproduce the bug in a unit test like this:

public void testGetResource() throws Exception {
String file = "myfile.arc";
Long offset = 123xxx765L;
ArcResource resource = (ArcResource) ResourceFactory.getResource(file, offset);
assertTrue(resource.getArcRecord().getPosition() < resource.getRecordLength());
}

as the bug manifests itself in reading beyond the end of the arcrecord while parsing the http headers.

[egh]

Thanks, Colin!

[egh]

See closed pull request #104 .

[csrster]

All good by me.

[anjackson]

So, trying to reproduce this in webarchive-commons along, I found that uncompressed ARCs should never have worked when invoked the fpath way. The reference pull request for webarchive-commons addresses that...

BUT it's symptoms are not consistent with the issue reported here. Not sure how to proceed unless we can make this bug more reproducible.

[anjackson]

Probably sensible to wait for the next BETA release to re-test this issue.