Gets rid of the need to seek to the end of the file
when opening a file.
The downside of this is that we waste a little space,
since we can't know in advance exactly how much
space the compressed parts of the headers will need.
This is useful for the way Dolphin scrubs Wii discs.
The encrypted data is what gets zeroed out, but this
zeroed out data then gets decrypted before being stored,
and the resulting data does not compress well.
However, each block of decrypted scrubbed data is
identical given the same encryption key, and there's
nothing stopping us from making multiple group entries
point to the same offset in the file, so we only have
to store one copy of this data per partition.
For reference, wit zeroes out the decrypted data,
but Dolphin's WIA writer can't do this because it currently
doesn't know which parts of the disc are scrubbed.
This is also useful for things such as storing Datel discs
full of 0x55 blocks (repesenting unreadable blocks)
without compression enabled.
This is intended to catch WIA files which have been created using
wit's default parameters (40 MiB block size), once the WIA PR is
merged. The check does however also work for GCZ files – not that
I think anyone has a GCZ file with a block size that large.
There was a race condition between two PRs incrementing the
array size. CI didn't catch it because the PR that was merged
last (PR #8824) wasn't rebuilt after the first PR was merged.
canonicalPath is orders of magnitude slower as it has to perform actual
disk I/O to resolve symlinks, which makes sorting by this column
ridiculously slow for large game lists, especially if the games are on
a NAS. We probably don't need that, simply resolving relative paths
should be sufficient.
std::result_of is deprecated in C++17, and removed in C++20. Microsoft
has gone ahead with the removal as of Visual Studio 16.6.0, so before
this change our code is broken there.
