Ticket #617 (Open)Mon Sep 25 18:48:18 UTC 2023
Bzip2 support in SparkFS
| Reported by: | Cameron Cawley (3514) | Severity: | Enhancement |
| Part: | RISC OS: Application | Release: | |
| Milestone: | Status | Open |
Details by Cameron Cawley (3514):
I’m not sure if it’s better to post this here or on the forums, but these are my thoughts on Bzip2 support:
- I’ve put together an initial port of the command line tool that doesn’t depend on UnixLib, so can be built with Norcroft: https://gitlab.riscosopen.org/ccawley/bzip2
- The repository also supports building and installing the library, which I haven’t tested much, but should be useful for supporting bzip2 compression in zip files. For standalone files, it should be sufficient for SparkFS to run the command line tool as a separate process, similarly to how it handles gzip files.
- I’m not aware of bzip2 containers having a way of storing metadata, so the file type is lost after compression. The Unix version does support copying the timestamp and permissions from the source file, but this isn’t implemented on RISC OS yet. What would be the best thing to do here?
- Is it useful to provide a module similar to the ZLib module? It might help to reduce code duplication, but it might not be possible to provide all of the high level functions because some of them directly use stdio.h structures. The callbacks for memory allocation might also be a problem because of calling conventions.
Changelog:
Modified by Sprow (202) Wed, October 04 2023 - 20:30:16 GMT
> I’m not sure if it’s better to post this here or on the forums
Bzip2 support specifically in SparkFS is one of the roadmap items (https://www.riscosopen.org/wiki/documentation/s…) so if you’re planning on following this all the way to SparkFS integration I’d suggest moving the item down from the Proposed section to In progress via self initiative and create a wiki page if appropriate.
Opening a ticket here’s a bit futile if you yourself then implement it almost immediately! The ticket system isn’t really intended to be a jotter for ideas or a place to canvas for opinions I don’t think – not enough feet walk over this path.
Specifically for SparkFS:
- It’s nice to see it’s cleanly portable and few dependencies
- Agree bzip2 is a monolithic file compressor so I’d handle it exactly like SparkFS does tar.gz files (extract the gzip, hand contents on to tar)
- Wrapping it in a module with an API sounds like 2nd level – the ZLib module is actually quite complicated, while zlib itself isn’t, I’d expect similar for bzip2 and wouldn’t try to swallow that whole personally
- For SparkFS I’d build it as a library in the partially-linked-AOF-archived-by-libfile sense and link SparkFSApp against it purely for source code management purposes
