You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to have the ability to Walk over io.ReadClosers and not just file paths.
Why is this feature a useful, necessary, and/or important addition to this project?
Although I understand this is somewhat of a niche need, it's conceivable that a ZIP file could contain more ZIP files nested within it. By providing a such a method, it would be possible to inspect the contents of the inner ZIP/Tar/Rar, something along the lines of:
I think (but might be wrong) it's not possible to read just the inner ZIP EOCD and correctly map each entry to the correct byte offsets (due to the potential several layers of compression).
The text was updated successfully, but these errors were encountered:
I think this is a great idea, not just for the nested reads you mentioned, but for any case where you have the archive not as a file on disk, but abstracted away as an io.Reader. The only difficulty with the implementation seems to be that right now the code uses the file extension to infer the type of file, so to implement this feature, a header-based format autodetection would need to be implemented.
I think #302, which will soon become v4 of this package, allows this because every file that you walk can be handled with an arbitrary callback function, and that function could be simply starting another walk. I rewrote the entire thing and got rid of the reliance on file extensions as well (except for optionally matching unknown files to formats, which can use extension or peeking the stream, or both). We can reopen this issue if it remains unresolved and needs more discussion.
What would you like to have changed?
I'd like to have the ability to Walk over
io.ReadCloser
s and not just file paths.Why is this feature a useful, necessary, and/or important addition to this project?
Although I understand this is somewhat of a niche need, it's conceivable that a ZIP file could contain more ZIP files nested within it. By providing a such a method, it would be possible to inspect the contents of the inner ZIP/Tar/Rar, something along the lines of:
I think (but might be wrong) it's not possible to read just the inner ZIP EOCD and correctly map each entry to the correct byte offsets (due to the potential several layers of compression).
The text was updated successfully, but these errors were encountered: