lexa wrote:Hi Tomas,
I agree: This is not so high on priority, but it looks ... mmh ... strange if such a very nice + powerful tool like Salamander is not (or no more) able to determine the size of gzipped files. That's an open (not proprietary) and well documented format for (de-)compressing files. And thinking the next, when Salamander is going to unpack, how will it calculate the available diskspace for warnings...?
Yes, gzip is open and documented format (I would probably leave out the "well" word here, I had studied the documentation quite hard, but it could be worse
). The trouble is that it's not one definitive format, it's several versions of such. And there are a lot of programs creating gzip archives, and not all of them adhere to the original format specification. So it's not that easy to support.
lexa wrote:
In Salamanders default configuration, the following filetypes are associated to the one-for-all "TAR" plugin: "tgz;tbz;taz;tar;gz;bz;bz2;z;rpm;cpio;deb"
So I miss the "tar.gz". How is it handled? It looks like same as ".gz". But why different results? ...see 2.)
Maybe a separate g[un]zip Plugin for gzipped files is the solution?
No need to separate it.
tar.gz is completely different case. That's a tar archive compressed with gzip. The information Salamander displays are taken from the tar archive, not from gzip. The same holds for tar.bz, tar.Z etc.
lexa wrote:
1.) Study of the gzip sources may help you:
Code: Select all
me:/srv # gzip --list bigfile.txt.gz
compressed uncompressed ratio uncompressed_name
200774480 3217555456 93.8% bigfile.txt
Not sure how this is handled, maybe gzip format got another format variant
. The format description included in gzip sources clearly states that at the end of the file are:
4 bytes uncompressed input size modulo 2^32
That's the only place mentioning the size. And from our experience, even this information is sometimes not present. And I am not even starting about gzip with multiple streams. To get a slightly better idea of the problem, try googling a bit, you may find e.g.
http://stackoverflow.com/questions/9715 ... -gzip-file. In short, the only reliable way to find out the size of the uncompressed file is to decompress it. We were considering this option, but we decided that the time it takes to decompress the file is not worth the information (although e.g. for the tar.gz format you mentioned it is done, as there is no other way to list the contents).
So, although I agree that the current behavior is not optimal, we think it is still the best. The only improvement we may do in the future is to remove the zero or remove the size column altogether. Sorry...
lexa wrote:
2.) See my new screenshot below, how Salamander handles and shows *.tar.gz files in another way as *.gz. I think, there must be a way in your own code to do this.
As I mentioned above, tar.gz is taking the information from different source, it's basically completely different archive.
lexa wrote:
So Tomas, I'll do my best so that should be my last try to confuse you with my .gz problem
.
Well, if you find any usable information how to get the size reliably (by reliably, I mean it works in 100% cases, we are not interested in any heuristics which only mostly works), then feel free to come back and I will do my best to fix the problem. But at this time, it would be a change from one bad state to another, and that's not worth my time, sorry.
.