[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32824: additional info
From: |
Assaf Gordon |
Subject: |
bug#32824: additional info |
Date: |
Mon, 24 Sep 2018 14:14:42 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
Hello,
On 24/09/18 01:18 PM, Coleman, Patrick EX1 wrote:
I'm beginning to suspect the supplier that is sending in the zipped
files is unaware what compression utility they're using and/or
version... the only 3.0 compression utility I'm finding is WinZip.
More likely (if they are on AIX) that they are using info-zip
(http://infozip.sourceforge.net/) which is at version 3.0.
On most gnu/linux system, you should have the "file" utility installed,
which can be used to detect the file type.
Examples:
=====
$ file unknown1.bin
unknown1.bin: Zip archive data, at least v2.0 to extract
$ file unknown2.bin
unknown2.bin: gzip compressed data, last modified: Mon Sep 24 13:26:32
2018, from Unix
=====
I think the file is failing to unzip due to the file not being
completely downloaded. Appears truncated. Any thoughts you can
provide though on Gzip 3.0 would be helpful, thanks.
A good way is to ask the sender to calculate the checksum
of their file before uploading it.
Then you can calculate the checksum of the downloaded file.
If they are not exactly the same - you have some corruption.
On AIX, they should run:
$ shasum archive.bin
f572d396fae9206628714fb2ce00f72e94f2258f archive.bin
After you download the file, check again:
$ sha1sum archive.bin
f572d396fae9206628714fb2ce00f72e94f2258f archive.bin
(Note the program name is "shasum" on AIX and "sha1sum" on gnu/linux).
hope this helps,
- assaf