reader;
reader->SetURILoader(loader); // other relative files will be resolved and loaded from the zip
reader->SetStream(stream);
```
To support them in the URI loader there are different approach, either the base file name must be a zip (last component), or do something higher level by resolving zip in full paths, but that would be tricky.
* * *
About Seek support, note that the libzip indicates that compressed archives do not support seeking, and uncompressed ZIP are uncommon.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [January 26, 2026, 3:51pm UTC](https://discourse.vtk.org/t/adding-support-for-opening-any-archived-single-file/16254/3 "2026-01-26T15:51:41Z")
> [@alexy.pellegrini](#):
>
> I think it would be good to support them in the vtkURILoader,
Indeed, that would be interesting in the context of glTF and we should add URI loader support to other readers/importers as well.
> the libzip indicates that compressed archives do not support seeking
Unfortunate, where did you find that info ?
---
### Author:  [@alexy.pellegrini](https://discourse.vtk.org/u/alexy.pellegrini)
#### Post date: [January 26, 2026, 3:55pm UTC](https://discourse.vtk.org/t/adding-support-for-opening-any-archived-single-file/16254/4 "2026-01-26T15:55:20Z")
In the link you gave:
> The [`zip_fseek`](https://libzip.org/documentation/zip_file_is_seekable.html#zip_fseek)() function seeks to the specified offset relative to whence, just like [fseek(3)](http://pubs.opengroup.org/onlinepubs/9699919799/functions/fseek.html).
> `zip_fseek` only works on uncompressed (stored), unencrypted data. When called on compressed or encrypted data it will return an error.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [January 26, 2026, 3:57pm UTC](https://discourse.vtk.org/t/adding-support-for-opening-any-archived-single-file/16254/5 "2026-01-26T15:57:08Z")
Next time I will try reading 🙂
Anyway, it indeed shows that the Seek issue I highlight may be critical, unless we find another third party that can indeed Seek.
---
### Author:  [@toddy](https://discourse.vtk.org/u/toddy)
#### Post date: [February 3, 2026, 11:27pm UTC](https://discourse.vtk.org/t/adding-support-for-opening-any-archived-single-file/16254/6 "2026-02-03T23:27:55Z")
Why not just read the compressed stream into an uncompressed (buffered) one then Seek() on it.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [February 4, 2026, 7:55am UTC](https://discourse.vtk.org/t/adding-support-for-opening-any-archived-single-file/16254/7 "2026-02-04T07:55:30Z")
This is indeed a possible fallback, but not ideal when dealing with larg files.
---
### Author:  [@toddy](https://discourse.vtk.org/u/toddy)
#### Post date: [February 5, 2026, 3:24am UTC](https://discourse.vtk.org/t/adding-support-for-opening-any-archived-single-file/16254/8 "2026-02-05T03:24:34Z")
I suppose that depends on whether you need to seek to the end of the file or just in chunks no larger than the decompressed buffer.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [February 9, 2026, 1:57pm UTC](https://discourse.vtk.org/t/adding-support-for-opening-any-archived-single-file/16254/9 "2026-02-09T13:57:57Z")
With no further feedback, I’ll design a proper solution.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [February 9, 2026, 4:37pm UTC](https://discourse.vtk.org/t/adding-support-for-opening-any-archived-single-file/16254/10 "2026-02-09T16:37:22Z")
Here is a quick analysis of potential 3rd parties:
| | zlib | minizip(zlib) | libzip | libarchive |
| --- | --- | --- | --- | --- |
| .gz | ✅ | ✅ | ✅ | ✅ |
| .xz | ⛔ | ⛔ | ✅ | ✅ |
| .tar.gz | ✅ | ✅ | ✅ | ✅ |
| .tar.xz | ⛔ | ⛔ | ✅ | ✅ |
| .zip | ⛔ | ✅ | ✅ | ✅ |
| .rar | ⛔ | ⛔ | ⛔ | ✅ |
| .7z | ⛔ | ⛔ | ⛔ | ✅ |
| popular | ✅ | ✅ | ⚠ | ✅ |
| maintained | ✅ | ✅ | ⚠ | ✅ |
| support stream | ✅ | ✅ | ⛔ | ✅ |
| support seek | ⛔ | ⛔ | ⛔ | ⛔ |
| in VTK/PV/PVSB | ✅ | ⚠ | ⛔ | ⛔ |
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [February 9, 2026, 5:02pm UTC](https://discourse.vtk.org/t/adding-support-for-opening-any-archived-single-file/16254/11 "2026-02-09T17:02:18Z")
**libarchive** is the clear winner here! Seek support is just not possible with most compression algorithm so lets consider it not possible. A pure zlib backend would be nice but this doesnt seem necessary after all.
I’ll design assuming libarchive usage.
---
### Author:  [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [February 10, 2026, 10:58am UTC](https://discourse.vtk.org/t/adding-support-for-opening-any-archived-single-file/16254/12 "2026-02-10T10:58:54Z")
Here is a tentative API:
```auto
vtkCompressedResourceStream : public vtkResourceStream
{
SupportSeek () { return false; };
Read (void *buffer, std::size_t bytes); // impl using libarchive
EndOfStream(); // impl using libarchive
Tell(); // impl using libarchive
}
vtkCompressedFileResourceStream : public vtkCompressedResourceStream
{
Open(const std::string& archive, const std::string& file) // impl using libarchive
}
vtkCompressedMemoryResourceStream : public vtkCompressedResourceStream
{
SetBuffer(const void *buffer, std::size_t size) // impl using libarchive
}
```
Contrary to vtkMemoryResourceStream, the suport of copying the memory into its own buffer seems not needed for this specialized stream, but it could be added in the future.
The URI loader support suggested by @alexy.pellegrini above is considered outside of the scope at the moment.