Request: Open CAB without fopen

[bwrsandman]

Would it be feasible to add a function to the library that allows opening a CAB file from memory such as this?

Unshield* unshield_open_from_buffer(const char* filename, const void* buffer, size_t buffer_size);

This would allow the piping the contents of cab files from zlib or libcdio without doing a round trip to the filesystem.

[twogood]

I'm not sure that would work, as both the .cab and the .hdr files are needed at the same time but only the .cab file need to be specified on the command line and the .hdr file is found by changing file suffix. If the logic for opening with different suffix could be overridden you could probably send in /dev/fd/X as path for .cab and .hdr.

[twogood]

There is also the support for multiple .cab files. And the code does ftell and fseek to find out the size of files.

[bwrsandman]

Perhaps an interface where I can supply my own io callbacks instead of using fopen, fseek, ftell?

I've seen this done with minizip's unzOpen2
https://github.com/luvit/zlib/blob/master/contrib/minizip/ioapi.h#L172
https://github.com/luvit/zlib/blob/master/contrib/minizip/unzip.h#L184

This should be enough to support hdr files and multiple CAB files as the callbacks would require my implementation to extract those extra files from libcdio.

[twogood]

That's a neat abstraction! Quite a makeover to implement though.

[bwrsandman]

Posted a proposed implementation of io callbacks.
I was able to list contents of a cab file inside of a cue/bin pair read with libcdio:
https://github.com/bwrsandman/unshield/blob/io_callbacks_example/src/isocab.c#L80-L366

[bwrsandman]

Any possible update on this?

Virtual filesystem support would benefit usecases where file system is restricted or slow: i.e. android, web assembly, read-only file systems.

[bwrsandman]

This has been delivered in #112

Any idea when a version will be released with this change?

[twogood]

This has been delivered in #112

Any idea when a version will be released with this change?

I guess I can make a new release anytime, and maybe i should merge #180 first?

[bwrsandman]

That's right but no immediate rush.