A deep-copy method CopyReader has been added to BlobReader (virtual) and all of its subclasses (override). This should create a second BlobReader to open the same set of data but with an independent read pointer so that it doesn't interfere with any reads done on the original Reader. As part of this, IOFile has added code to create a deep copy IOFile pointer onto the same file, with code based on the platform in question to find the file ID from the file pointer and open a new one. There has also been a small piece added to FileInfo to enable a deep copy, but its only subclass at this time already had a copy constructor so this was relatively minor.
Previously, we had WBFS and CISO which both returned an upper bound of the size, and other formats which returned an accurate size. But now we also have NFS, which returns a lower bound of the size. To allow VolumeVerifier to make better informed decisions for NFS, let's use an enum instead of a bool for the type of data size a blob has.
New dolphin-tool command: "header" -b / --block_size -c / --compression -l / --compression_level Informative RVZ/WIA header2 value "compression_level" is now a s32 instead of a u32, because negative compression is a thing. Speaking of, it is now possible to use negative compression levels in dolphin-tool's convert command (not the GUI, though).
SPDX standardizes how source code conveys its copyright and licensing information. See https://spdx.github.io/spdx-spec/1-rationale/ . SPDX tags are adopted in many large projects, including things like the Linux kernel.
DiscIO: Rework the implementation of TGC reading
Fixes https://bugs.dolphin-emu.org/issues/10654. To quote the documenation file included with the program tgctogcm: "TGC's are miniaturized .gcm images with a 32kB header. The embedded gcm contains some bogus data, namely: -FST Location (0x424 in gcm) -DOL Location (0x420 in gcm) -FST File offsets (all files are offset/spoofed by a certain amount)" Dolphin has been handling the values at 0x420 and 0x424 by simply overwriting them with a working value (just like tgctogcm does), but it has used a different approach for the file offsets in the FST. Instead of changing the offsets that are stored in the FST, Dolphin changed where the files actually are placed on the virtual disc. My hope was that this would make the loading times more accurate to how they are when running a TGC file as part of a larger disc. However, there are TGC files where we would need to move files backwards on the disc in order to do this (this is what issue 10654 is about), so the approach we have been using is flawed. This change makes Dolphin overwrite offsets in the FST instead, like tgctogcm does. Other than making Dolphin handle the affected TGC files correctly, this change also makes it so that unnecessary padding data isn't written if you use Dolphin to convert a TGC file to an ISO file. This feature is not actually implemented in Dolphin as of now, but I'm planning to add it in the near future as part of a larger feature.
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.