instance-based/global.json

{
  "sdk": {
    "version": "10.0.302",
    "rollForward": "disable"
  }
}
Switch to bullseye for building 2020-05-24 09:00:27 +01:00			`{`
			`"sdk": {`
Some clean up 2026-08-01 12:43:44 +01:00			`"version": "10.0.302",`
Try to make things an exact match 2026-06-12 15:10:15 +01:00			`"rollForward": "disable"`
Switch to bullseye for building 2020-05-24 09:00:27 +01:00			`}`
Fix RAR5 async decompression corruption in UnpWriteBufAsync Three bugs in the async version of UnpWriteBuf (used only in the async decompression path) were causing data corruption when decompressing RAR5 archives containing executable filters (E8/E8E9/ARM) whose blocks spanned the 4MB write boundary (UNPACK_MAX_WRITE): 1. WrittenFileSize was only incremented inside `if (OutMem != null)`, but should always be incremented after ApplyFilter (matching sync behavior). 2. UnpSomeRead = true was missing from the filter processing path. 3. In the NotAllFiltersProcessed else branch (filter intersects write border): - WrPtr was not updated to WrittenBorder, corrupting the window pointer used to compute WriteBorder on the next flush cycle - Remaining filters had NextWindow set to true (inverted logic), when sync correctly sets them to false so they are processed next time All three changes align the async path with the sync UnpWriteBuf logic. 2026-08-01 03:40:04 +00:00			`}`