Autoload of striped images

[blschatz]

This patch fixes building on current MacOS and adds support for automatically loading dependent striped image containers that are stored in the same folder as a container that has been opened.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.

:white_check_mark: blschatz
:white_check_mark: scudette
:x: Bradley

---

Bradley seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[scudette]

Still waiting on CLA for this. Please also check indentation - seems to be wrong in places.

[jtsylve]

I could be reading it wrong, but does this patch auto load any and all aff4 images in the same directory as the one the user is specifying? If so, this patch will break assumptions made by the c bindings. Currently in the C bindings the first AFF4 standard image is opened. If a user has multiple (unrelated) AFF4 images in the same directory, this patch will likely break that assumption in some cases.

I suggest we agree on a naming standard for split/striped images and limit the auto loading to images that fit that standard.

In the past we've discussed image.aff4 as the base image that users would select for loading and image.aff4.%u where %u is a segment number.

Thoughts?

[scudette]

This seems to be a convenience patch at best - it just saves a user from adding a * after the file name - i.e. aff4imager -e foobar image.aff4.*.

Do we really care that much? It would not be a good idea if it went off and automatically loaded all the images in the same directory for no reason.

[blschatz]

The purpose of the patch is to enable any consumer of the c-aff4 library to open the Striped Canonical Reference Images.

The patch doesn't load all images in the folder. This resolution mechanism is only executed when an open Map contains references to unresolved image Streams, so is not even executed for single container images; for striped images it is very lightweight. What it does is quickly build a map of VolumeID to Container files by scanning the first 1k or so of each AFF4 file in the same folder.

This is the easiest way to ensure interoperability with the Standard. Without the patch, consumers need specify all additional containers required to materialise the Map.

Joe, I agree that creating a standardised naming scheme for striped/multi part images is a good idea moving forward - more from a UX perspective than from a technical one.

[blschatz]

Michael, The spacing related commits make the relevant lines consistent with the wider indent style. The majority of the surrounding code uses spaces, whereas those few lines used tabs.

[jtsylve]

This project benefit from the use of a .clang-format file or similar to deal with the formatting issues consistently.