I have used archives from C++ before, but not without using a very large helper library. Has anyone accessed files and directories from tarballs from C without extracting them to a temporary location? Before, I used a library for Qt, but that's Qt...
Any thoughts?
AHelper wrote:
I have used archives from C++ before, but not without using a very large helper library. Has anyone accessed files and directories from tarballs from C without extracting them to a temporary location? Before, I used a library for Qt, but that's Qt...
Any thoughts?
http://www.gzip.org/#sources
Yes, I have looked there, I don't know if that is the best choice. Besides, that would only take care of gzip (which I might not use), I am looking for tar reading. I don't know if I should use libtar or zlib or...
AHelper wrote:
Yes, I have looked there, I don't know if that is the best choice. Besides, that would only take care of gzip (which I might not use), I am looking for tar reading. I don't know if I should use libtar or zlib or...
actually, if you get the BSD gzip distribution, I think that also supports bzip2.
libarchive?
Rolling your own gzip decompressor with zlib is pretty easy (just peel off the small gzip header and checksum, then undeflate it). Tarballs are easy to decode as well.
When you get down to it, you either need a large all-encompassing library, or a few common ones and a sizable chunk of your own code.
Tari wrote:
libarchive?
Rolling your own gzip decompressor with zlib is pretty easy (just peel off the small gzip header and checksum, then undeflate it). Tarballs are easy to decode as well.
When you get down to it, you either need a large all-encompassing library, or a few common ones and a sizable chunk of your own code.
libarchive seems nice. I will look into it later on today.
Well if you plan on just using a tarball, is there any reason why you couldn't just roll your own archive format? That way, you can access your data in any way you see fit.
I don't want to reinvent the wheel ๐
Could I reinvent it for you?
Kaslai wrote:
is there any reason why you couldn't just roll your own archive format?
Interoperability
If he's only using it among his own programs, interoperability isn't that big of a deal. I just looked at the tarball format though, and it's blindingly simple. In fact, it's almost exactly like the archive format I wrote for myself, just without a header containing the file tree. You could probably write a lightweight tar library fairly easily with very little code.
Firstly, elfprince++ for saying interoperability (as I couldn't remember that :-X ). This is not new format, it is based off of the ipk format. The specs say that it is a simple tarball with data/control sections as tar.gz's and a version file. I need a tar (compressed or not) with the data section as a folder and a spec file. If I made a new format, it wouldn't work in programs like ark, file roller, 7zip ( <3 ), etc.. This package is not sent to the calc, so why reinvent the wheel? Using a premade library (ty Tari, libarchive works great!) very quickly is much better than making your own in many ways.
Taking this further, if I uploaded 3d_prizm_quake1_demo.wtfizthisformat, nobody would be able to open it ๐
I notice the topic only now, through saxjax.
I see that Tari has already mentioned libarchive, which would have been my suggestion as well ๐
Why not just use C++ if you already know how to use it with some library?
Kllrnohj wrote:
Why not just use C++ if you already know how to use it with some library?
Because that library requires Qt, and daemons shouldn't be linked to GUI libraries...
AHelper wrote:
Because that library requires Qt, and daemons shouldn't be linked to GUI libraries...
Qt isn't just a GUI library and there's no reason a daemon can't link against it. You can totally make console Qt apps.