mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-09-01 18:25:19 +02:00
Henrik Rydgård
f7f92c5db7
SaveIntoCache checked `readBytes != 0` instead of comparing against the full expected length, so any nonzero-but-short read from the backend (e.g. a Remote ISO connection dropping mid-file) was treated as a complete success: in the multi-block path this marked *all* requested blocks (up to 16) as fully cached and wrote the uninitialized tail of the read buffer to the on-disk cache file, and in both paths the short/uninitialized data was also copied straight into the caller's output buffer and counted in the return value - so a read failure was reported (and permanently cached) as success. Only treat a block as read once the backend actually delivered the full blockSize_ for it, and stop before caching or returning anything for blocks it didn't. Also fixes two latent bugs in the same functions, unreachable in the current call graph (DiskCachingFileLoader is only ever driven by CachingFileLoader, which always issues block-aligned reads) but wrong if ever called otherwise: - The multi-block loop reused the batch's initial `offset` (the position within the *first* block) for every subsequent block instead of resetting it to 0, which would both read from the wrong place in `wholeRead` and mis-copy less than a full block for i > 0. - ReadBlockData() applied `offset` to the destination pointer instead of the file seek position, which would both read the wrong bytes from disk and write up to `offset` bytes past the end of the caller's buffer. LoadCacheIndex's sanity check on persisted block indices used `>` instead of `>=` against maxBlocks_ (blockIndexLookup_ only has maxBlocks_ entries, valid indices 0..maxBlocks_-1), so a corrupted cache file's index entry with block == maxBlocks_ exactly would pass validation and then index one past the end of blockIndexLookup_.