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.
When SeekableSharpCompressStream.StopRecording() was called (e.g. after the tar
probe in GZipFactory.TryOpenReader), it cleared _recordedPosition without seeking
back to it. This left the underlying FileStream at the advanced position reached
during the probe, so the subsequent GZipReader would start reading from the
wrong offset, producing Key=null and 0 extracted bytes.
Fix: seek back to _recordedPosition before clearing it, matching the behavior of
the non-seekable SharpCompressStream.StopRecording() which rewinds _logicalPosition.
Also enhance the existing GZip_ReaderFactory_FlatGZip test to actually verify the
extracted content (not just MoveToNextEntry returns true), and add an async variant.
Closes#1391
The Zip64 branch of the streaming header reader assumed a data descriptor always follows a >=4GB entry. When the entry instead has back-patched sizes (no descriptor), the following header was parsed as descriptor fields, overwriting the entry's correct size/CRC with central-directory 0xFFFFFFFF sentinels and, on non-seekable async streams, leaving the reader misaligned so the next entry threw.
Now it detects a header signature after the entry data and leaves the already-correct metadata untouched, parsing that header normally. The fix has been applied to both the sync and async readers.
