Fix inconsistent casing in Windows acquisitions #281
Description
This has long been an outstanding issue that basically has plagued everyone but a few internal use cases :)
As also referenced in #171, path names have inconsistent casing for any collection from a case-insensitive filesystem. This causes a whole bunch of issues in post processing and inspection. We (Fox-IT) "solve" this in "post" in the acquire loader in dissect.target where we normalize the paths, but that's not a proper solution. Sometimes you just have to extract an acquire tarball for manual inspection or inspection with a different tool.
We should aim to solve this proper. Yes, ASDF will not have this issue, but we should still strive to solve this for tar and directory collections.
My gut feeling tells me that the root cause of this is the way we determine paths in dissect.target. We (used to, I think we still do) take the user-provided path as-is as the full path/filename, including any casing in the user-provided path. However, we should instead only use the user-provided path as means to resolve the proper file entries, and then take the path/build it from the proper file names. fox-it/dissect.target#1389 should hopefully help in this.
The above is just a feeling, I haven't properly looked into this, but we should take that as a lead to investigate further. I'm also not entirely sure how this will work with TargetPath/pathlib.Path. Perhaps .resolve() could be a way to do this? As I think pathlib.Path currently also just takes the user-provided value as-is. I hope .resolve() resolves it to the proper casing though (citation needed).