[PR #894] [MERGED] Fix condition in rar v3 code #1315

Open
opened 2026-01-29 22:19:56 +00:00 by claunia · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/adamhathcock/sharpcompress/pull/894
Author: @Morilli
Created: 2/11/2025
Status: Merged
Merged: 2/11/2025
Merged by: @adamhathcock

Base: masterHead: fix-rare-solid-rar-failure


📝 Commits (4)

  • 94789ce Fix condition in rar v3 code
  • 04b2501 Merge branch 'master' into fix-rare-solid-rar-failure
  • a77c03f add comment and change the same code in new Unpack50
  • eb5db17 revert change to rar5 code

📊 Changes

1 file changed (+4 additions, -2 deletions)

View changed files

📝 src/SharpCompress/Compressors/Rar/UnpackV1/Unpack.cs (+4 -2)

📄 Description

This was an interesting one to track down. Basically, when UnpWriteData is called with a size of 0, it must call writeStream.Write even if destUnpSize is 0 to ensure that Suspended is set to false.
The same condition change must be done here: 94789ce455/src/SharpCompress/Compressors/Rar/UnpackV1/Unpack.cs (L266)
to make sure that the code passes over both if (destUnpSize < 0) and if (suspended) conditions and continues below.

While investigating this bug I found some other issues in the rarVM code, but I'm not sure how to test them and whether that code is even still used nowadays.

TODO: Find some example archive that shows this bug that isn't 40MB and add a test case for it.


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/adamhathcock/sharpcompress/pull/894 **Author:** [@Morilli](https://github.com/Morilli) **Created:** 2/11/2025 **Status:** ✅ Merged **Merged:** 2/11/2025 **Merged by:** [@adamhathcock](https://github.com/adamhathcock) **Base:** `master` ← **Head:** `fix-rare-solid-rar-failure` --- ### 📝 Commits (4) - [`94789ce`](https://github.com/adamhathcock/sharpcompress/commit/94789ce455cf88cbe0636abc0071c1c03d4a2ebf) Fix condition in rar v3 code - [`04b2501`](https://github.com/adamhathcock/sharpcompress/commit/04b25011e96017287d567dd94385b69a3f386190) Merge branch 'master' into fix-rare-solid-rar-failure - [`a77c03f`](https://github.com/adamhathcock/sharpcompress/commit/a77c03fcaf3eedc84f35d1a38e45701d83a445b0) add comment and change the same code in new Unpack50 - [`eb5db17`](https://github.com/adamhathcock/sharpcompress/commit/eb5db176fa4f56cde730e0b67ee66e2c25d498e4) revert change to rar5 code ### 📊 Changes **1 file changed** (+4 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `src/SharpCompress/Compressors/Rar/UnpackV1/Unpack.cs` (+4 -2) </details> ### 📄 Description - closes #890 This was an interesting one to track down. Basically, when `UnpWriteData` is called with a size of `0`, it must call `writeStream.Write` even if `destUnpSize` is 0 to ensure that `Suspended` is set to false. The same condition change must be done here: https://github.com/adamhathcock/sharpcompress/blob/94789ce455cf88cbe0636abc0071c1c03d4a2ebf/src/SharpCompress/Compressors/Rar/UnpackV1/Unpack.cs#L266 to make sure that the code passes over both `if (destUnpSize < 0)` and `if (suspended)` conditions and continues below. While investigating this bug I found some other issues in the rarVM code, but I'm not sure how to test them and whether that code is even still used nowadays. TODO: Find some example archive that shows this bug that isn't 40MB and add a test case for it. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
claunia added the pull-request label 2026-01-29 22:19:56 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#1315