Closed stormi closed 1 month ago
If I used .tar
, then it's likely that's what I got when I tested.
Is it possible that different versions of XenServer/XCP-ng produce different results?
It's always possible, but I doubt it. Aren't you the one compressing the file in https://github.com/vatesfr/xen-orchestra/commit/d384c746cacf0dedf4130fabc02019a819a09e48#diff-831d0ae3a720846325d91f35b5746bd3d9e2fbcb5cdbc02ed79411c4486d2194R194 ? I'm not sure I read the code well, but that's what it looks like to me.
I just tested in XCP-ng 8.3 and it's the same result as in an up to date XCP-ng 8.2.1
Yes, XO may be compressing, but it is setting the content-encoding
header accordingly which, I believe, will make the HTTP client decompress the result before passing it back (i.e. you should get a tar if it was originally a tar).
What I get is not a problem. The filename is, because, at least in firefox, it's still named logs.tar
in the filesystem after downloading. A compressed tar should be named either .tar.gz
or .tgz
. To me, XO should append .gz
to the name when compressing, in addition to setting the content-encoding
header.
I misread what you wrote. No, I do get a compressed tar (which I prefer actually) :
~/Téléchargements $ file logs.tar
logs.tar: gzip compressed data, last modified: Thu May 30 15:00:21 2024, from Unix, original size modulo 2^32 1047293300
Are you using XOA or XO from the sources?
XOA
Which release channel?
both
Provide your commit number
No response
Describe the bug
The logs archive that is produced by XO is actually a tar archive, compressed by gzip, but the filename doesn't reflect that, as it's called
logs.tar
instead oflogs.tar.gz
orlogs.tgz
. This confuses tools which assume that is it a plain, uncompressed, tarball, based on the file extension.Error message
No response
To reproduce
Go to a host's advanced tab, and click "Download system logs".
Expected behavior
No response
Screenshots
No response
Node
no idea
Hypervisor
Tested with XCP-ng 8.2
Additional context
No response