starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-08 13:34:57 +00:00
Code Issues 975 Packages Projects Releases 20 Wiki Activity

[PR #1053] Rationalize SourceStream vs Volumes with IByteSource abstraction #1477

New Issue
Open
opened 2026-01-29 22:20:46 +00:00 by claunia · 0 comments
claunia commented 2026-01-29 22:20:46 +00:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/adamhathcock/sharpcompress/pull/1053
Author: @Copilot
Created: 11/29/2025
Status: 🔄 Open

Base: master ← Head: copilot/rationalize-sourcestream-volumes

📝 Commits (6)

  • cef6d46 Initial plan
  • 75db75a Add IByteSource abstraction and documentation for Volume/SourceStream architecture
  • 3470f71 Remove unused _leaveOpen field from StreamByteSource
  • f2cde3a Refactor SourceStream to use IByteSource internally
  • b2b9e4e Add documentation to SharpCompressStream clarifying its role in the architecture
  • fb3d326 Document IStreamStack interface and its role in the architecture

📊 Changes

9 files changed (+609 additions, -85 deletions)

View changed files

📝 FORMATS.md (+32 -0)
📝 src/SharpCompress/Common/IVolume.cs (+52 -0)
📝 src/SharpCompress/Common/Volume.cs (+31 -0)
➕ src/SharpCompress/IO/FileByteSource.cs (+39 -0)
➕ src/SharpCompress/IO/IByteSource.cs (+100 -0)
📝 src/SharpCompress/IO/IStreamStack.cs (+64 -0)
📝 src/SharpCompress/IO/SharpCompressStream.cs (+49 -0)
📝 src/SharpCompress/IO/SourceStream.cs (+178 -85)
➕ src/SharpCompress/IO/StreamByteSource.cs (+64 -0)

📄 Description

  • Explore the codebase to understand SourceStream and Volume implementations
  • Analyze how different archive formats (Zip, Rar, 7Zip, Tar) use these abstractions
  • Understand the distinction between split archives, multi-volume archives, and SOLID archives
  • Create IByteSource interface to clarify the "stream of bytes" abstraction:
    • IByteSource: Core interface for byte sources
    • FileByteSource: File-based implementation
    • StreamByteSource: Stream-based implementation
  • Add documentation comments to clarify the relationships between abstractions:
    • Updated IVolume with comprehensive documentation
    • Updated Volume with documentation explaining the layered architecture
    • Updated SourceStream with documentation for split vs volume modes
    • Updated SharpCompressStream with documentation explaining its role as a buffering/position-tracking wrapper
    • Updated IStreamStack with comprehensive documentation explaining its role in enabling stream stacking
  • Update FORMATS.md with Stream and Volume Architecture section
  • Refactor SourceStream to use IByteSource internally:
    • SourceStream now maintains a List<IByteSource> instead of separate file/stream lists
    • Added new constructor that accepts IByteSource directly
    • Existing constructors wrap FileInfo/Stream in appropriate IByteSource implementations
    • Cleaner separation between raw byte sources and archive-specific Volume semantics
  • Analyzed SharpCompressStream: Does not need structural changes - serves buffering/position tracking purpose
  • Analyzed IStreamStack: Essential infrastructure for stream stacking - 30+ implementations, heavily used. Documented its purpose and relationship to other abstractions.
  • Ensure existing tests continue to pass (869 tests passed)
  • Code review: Fixed documentation issues
  • Security scan: No vulnerabilities found
Original prompt

This section details on the original issue you should resolve

<issue_title>Rationalize SourceStream vs Volumes</issue_title>
<issue_description>SourceStream now handles multiple files and streams while the intention of Volume was to represent that.

Having both abstractions seems wrong yet both are providing value.</issue_description>

<agent_instructions>Provide a plan for this considering the current implementations of Volumes and SourceStream as well as if formats have internal streams of bytes</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@adamhathcock I probably need to create an abstraction that a stream of bytes isn't the same as a File/Stream.

7Zip can have a contiguous stream of bytes for a file or files.
Rar can have a contiguous stream of bytes for files (SOLID).
A stream of bytes can be across Files/Streams</comment_new>

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

🔄 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/1053 **Author:** [@Copilot](https://github.com/apps/copilot-swe-agent) **Created:** 11/29/2025 **Status:** 🔄 Open **Base:** `master` ← **Head:** `copilot/rationalize-sourcestream-volumes` --- ### 📝 Commits (6) - [`cef6d46`](https://github.com/adamhathcock/sharpcompress/commit/cef6d4603b2b6f91f1ca694526bceedbd5370efd) Initial plan - [`75db75a`](https://github.com/adamhathcock/sharpcompress/commit/75db75a33ac4ce48e21f382460d2988d669a31c3) Add IByteSource abstraction and documentation for Volume/SourceStream architecture - [`3470f71`](https://github.com/adamhathcock/sharpcompress/commit/3470f71f831df8cf43735bcea813c0500de0d26d) Remove unused _leaveOpen field from StreamByteSource - [`f2cde3a`](https://github.com/adamhathcock/sharpcompress/commit/f2cde3abdc1d22158f52c07745b7bfa854117c6e) Refactor SourceStream to use IByteSource internally - [`b2b9e4e`](https://github.com/adamhathcock/sharpcompress/commit/b2b9e4ef7d75a93d7dc691f8b5a3a35fef3bb8b9) Add documentation to SharpCompressStream clarifying its role in the architecture - [`fb3d326`](https://github.com/adamhathcock/sharpcompress/commit/fb3d32622d618e8923b72076974d549aff057087) Document IStreamStack interface and its role in the architecture ### 📊 Changes **9 files changed** (+609 additions, -85 deletions) <details> <summary>View changed files</summary> 📝 `FORMATS.md` (+32 -0) 📝 `src/SharpCompress/Common/IVolume.cs` (+52 -0) 📝 `src/SharpCompress/Common/Volume.cs` (+31 -0) ➕ `src/SharpCompress/IO/FileByteSource.cs` (+39 -0) ➕ `src/SharpCompress/IO/IByteSource.cs` (+100 -0) 📝 `src/SharpCompress/IO/IStreamStack.cs` (+64 -0) 📝 `src/SharpCompress/IO/SharpCompressStream.cs` (+49 -0) 📝 `src/SharpCompress/IO/SourceStream.cs` (+178 -85) ➕ `src/SharpCompress/IO/StreamByteSource.cs` (+64 -0) </details> ### 📄 Description - [x] Explore the codebase to understand SourceStream and Volume implementations - [x] Analyze how different archive formats (Zip, Rar, 7Zip, Tar) use these abstractions - [x] Understand the distinction between split archives, multi-volume archives, and SOLID archives - [x] Create IByteSource interface to clarify the "stream of bytes" abstraction: - `IByteSource`: Core interface for byte sources - `FileByteSource`: File-based implementation - `StreamByteSource`: Stream-based implementation - [x] Add documentation comments to clarify the relationships between abstractions: - Updated `IVolume` with comprehensive documentation - Updated `Volume` with documentation explaining the layered architecture - Updated `SourceStream` with documentation for split vs volume modes - Updated `SharpCompressStream` with documentation explaining its role as a buffering/position-tracking wrapper - **Updated `IStreamStack` with comprehensive documentation explaining its role in enabling stream stacking** - [x] Update FORMATS.md with Stream and Volume Architecture section - [x] **Refactor SourceStream to use IByteSource internally**: - SourceStream now maintains a `List<IByteSource>` instead of separate file/stream lists - Added new constructor that accepts `IByteSource` directly - Existing constructors wrap FileInfo/Stream in appropriate IByteSource implementations - Cleaner separation between raw byte sources and archive-specific Volume semantics - [x] **Analyzed SharpCompressStream**: Does not need structural changes - serves buffering/position tracking purpose - [x] **Analyzed IStreamStack**: Essential infrastructure for stream stacking - 30+ implementations, heavily used. Documented its purpose and relationship to other abstractions. - [x] Ensure existing tests continue to pass (869 tests passed) - [x] Code review: Fixed documentation issues - [x] Security scan: No vulnerabilities found <!-- START COPILOT CODING AGENT SUFFIX --> <details> <summary>Original prompt</summary> > > ---- > > *This section details on the original issue you should resolve* > > <issue_title>Rationalize SourceStream vs Volumes</issue_title> > <issue_description>SourceStream now handles multiple files and streams while the intention of Volume was to represent that. > > Having both abstractions seems wrong yet both are providing value.</issue_description> > > <agent_instructions>Provide a plan for this considering the current implementations of Volumes and SourceStream as well as if formats have internal streams of bytes</agent_instructions> > > ## Comments on the Issue (you are @copilot in this section) > > <comments> > <comment_new><author>@adamhathcock</author><body> > I probably need to create an abstraction that a stream of bytes isn't the same as a File/Stream. > > 7Zip can have a contiguous stream of bytes for a file or files. > Rar can have a contiguous stream of bytes for files (SOLID). > A stream of bytes can be across Files/Streams</body></comment_new> > </comments> > </details> - Fixes adamhathcock/sharpcompress#1042 <!-- START COPILOT CODING AGENT TIPS --> --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --- <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:20:46 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
feedback requested
not bug
pull-request
Mirrored from GitHub Pull Request
 question
up for grabs
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#1477
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?