It's possible that new version of 7-Zip can solve your problems with 7z archives. So download latest version of 7-Zip and try to use that new version. You can try also latest alpha or beta version. If new version also doesn't help, read this manual.
7z archive consists of 4 main blocks of data:
Archive example: a.7z (3740 bytes) that contains 5 files compressed with LZMA method.
Start of archive:
0000000000: 37 7A BC AF 27 1C 00 04 5B 38 BE F9 59 0E 00 00
0000000010: 00 00 00 00 23 00 00 00 00 00 00 00 7A 63 68 FD
0000000020: 00 21 16 89 6C 71 3D AB 7D 89 E6 3C 2E BE 60 24
00: 6 bytes: 37 7A BC AF 27 1C - Signature
06: 2 bytes: 00 04 - Format version
08: 4 bytes: 5B 38 BE F9 - CRC of the following 20 bytes
0C: 8 bytes: 59 0E 00 00 00 00 00 00 - relative offset of End Header
14: 8 bytes: 23 00 00 00 00 00 00 00 - the length of End Header
1C: 4 bytes: 7A 63 68 FD - CRC of the End Header
Relative offset of End Header is relative from the end of Start Header,
that is at offset 0x20 (32 in decimal).
Real offset of End Header in example archive = 0x20 + 0x0E59 = 0x0E79
20: 00 21 16 89 ... - start of compressed data.
Note: if the file was compressed with LZMA method, the first byte
is always 00. If first byte is not 00, then archive uses
another method (it can be LZMA2 or encrypted data with AES).
End of archive:
End Header (offset = 0x0E59, length = 0x23): 0000000E70: 17 06 8D AD 01 09 80 0000000E80: AC 00 07 0B 01 00 01 23 03 01 01 05 5D 00 10 00 0000000E90: 00 0C 81 1A 0A 01 3C 70 52 F7 00 00 Possible values for first byte in End Header: 17 - End Header contains the link to Metadata Block. 01 - Metadata block is stored in End Header.
There are some possible cases when archive is corrupted:
Here we describe the case, when you can open archive and you see the list of files, but when you press Extract or Test command, there are some errors: Data Error or CRC Error.
It's pretty difficult to recover data for that case.
If archive was compressed in "Solid" mode, and you have exact copies of some files from archive, you can create similar archive with good copies of files with same settings and in same order, and replace "bad" parts of bad.7z with "good" parts from another good.7z. You must look listings of files in bad and good archives, logs of "test" command, and think about ways to replace bad parts.
The are no more instructions here for that corruption case.
If you try to open or extract archive and you see the message "Can not open file 'a.7z' as archive", it means that 7-Zip can't open some header from the start or from the end of archive.
In that case you must open archive in hex editor and look to Start Header and End Header.
Possible cases:
0000000000: 37 7A BC AF 27 1C 00 04 00 00 00 00 00 00 00 00 0000000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Then try to open archive, if you can open and you see the list of files, try Test or Extract command. Look also "Data errors or CRC errors" section in this page.
For example, if you have multi-volume archive: a.7z.001, ... , a.7z.009, but one part a.7z.008 is missing, just copy a.7z.007 to file a.7z.008, and 7-Zip will see correct size of archive. Or if some part was reduced, look the size of another parts and restore original (correct) size of "bad" part, so total size will be correct again, and 7-zip will be able to open headers.
7-Zip writes full Start Header only at the end of archive creation operation.
You can look to Start Header. If you see signature with version and zeros in another fields:
0000000000: 37 7A BC AF 27 1C 00 04 00 00 00 00 00 00 00 00 0000000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
then archive creation operation probably was interrupted by some reason. And in that case probably there are no Metadata Block and End Header at the end of archive.
Note: If archive is multi-volume, uncompleted Start Header is also possible, if first volume was copied before end of archive (last volume) was written. In that case archive is not corrupted. And 7-Zip can unpack such archive, if total size is correct and if there is correct End Header.
If Start Header is OK, you can calculate correct archive size and compare with the size of archive that you have.
If there is no End Header, you can not recover file names, timestamps, and another metadata, but probably it's possible to recover some data as raw file, and then it's possible to recover data from raw file with some parser.
We describe all steps with example:
We create some good archive. We use readme.txt (1565 bytes) form 7-Zip 9.20 as example file.
Create readme.txt.bz2, readme.zip, readme.txt.gzip and readme.txt.xz archives from readme.txt.
Create a.7z with LZMA method that contains all files:
readme.txt.bz2 readme.txt.gz readme.zip readme.txt readme.txt.xz
We have a.7z (3740 bytes). You can look that file in hex editor. It must have structure similar to structure of 7z file described above.
Now we currupt a.7z archive. We want to split archive into two parts:
Metadata block with End Header are not big for our test archive (smaller than 300 bytes).
We call "Split file..." command in 7-Zip File Manager and type "3000 100G" in "Split to volumes, bytes:" field (100G means that second part can not be larger than 100 GB).
We have two parts: a.7z.001 (3000 bytes) and a.7z.002 (740 bytes). Then we copy a.7z.001 to bad.7z and try to open bad.7z. And we get the message "Can not open file 'bad.7z' as archive", so we have corrupted archive.
We open bad.7z in hex editor
0000000000: 37 7A BC AF 27 1C 00 04 5B 38 BE F9 59 0E 00 00 0000000010: 00 00 00 00 23 00 00 00 00 00 00 00 7A 63 68 FD 0000000020: 00 21 16 89 6C 71 3D AB 7D 89 E6 3C 2E BE 60 24
We see that Start Header is OK.
We calculate correct archive size from Start Header fields values:
0x0E59 + 0x20 + 0x23 = 0x0E9C = 3740
Correct size is 3740 bytes, but our "bad.7z" is only 3000 bytes.
We look to the end of archive:
0000000B60: 55 73 EA 87 45 18 FC AD 67 0D 40 EF F4 41 49 63 0000000B70: 6A 87 54 70 32 6C B0 8F 76 2A 63 BF 12 5D 88 CD 0000000B80: 22 76 9F 97 05 3B 37 BE 49 CD F8 0A CC 67 FB FE 0000000B90: 17 2E 16 D5 1F 8C 5A 30 08 7F C6 E9 98 9F 00 F1 0000000BA0: A6 99 F9 ED 01 62 84 48 77 69 C7 65 21 21 42 66 0000000BB0: 48 F1 FE 79 06 08 25 68
And we don't see End Header at the end of archive.
Conclusion: archive probably was truncated.
Now we want to create another "good" 7z archive that contains good Start Header, End Header. and we want to place Compressed Data block from bad.7z inside that new "good" archive.
At first we look start of Compressed Data block in bad.7z:
0000000020: 00 21 16 89 6C 71 3D AB 7D 89 E6 3C 2E BE 60 24
If LZMA method was used, then first byte in compressed data is always 0 and high bit of second byte is also 0. So if we see 00 in first byte and from 00 to 7F in second byte, probably LZMA method was used (not LZMA2).
If first byte in compressed data is not 0 or if the value of second byte is higher then 7F, then it's not LZMA stream. It can be LZMA2 (or AES encrypted stream).
We must create new "good" 7z archive with same method as in bad.7z, and new archive must be much larger than bad.7z
So we select some big file for that new archive. In some cases you can use even bad.7z as that big file. But we use 7-zip.chm. We rename 7-zip.chm (91020 bytes) to file raw.dat and we compress raw.dat to raw.7z with LZMA method with big dictionary size value. The dictionary size must be equal or larger than dictionary size in bad.7z.
raw.7z is (84898 bytes) that is much larger than bad.7z, as required. if raw.7z is smaller than "bad.7z", you must create another raw.7z with another raw.dat that is larger.
We call "Split file..." function for bad.7z and type "32 100G" in "Split to volumes, bytes:" field.
It creates 2 parts:
We call "Split file..." function for raw.7z and type "32 2968 100G" in "Split to volumes, bytes:" field. Note that the value 2968 is equal to size of "bad.7z.002". When you recover real archive, you must use exact size of your bad.7z.002.
It creates 3 parts:
Then we rename bad.7z.002 file to raw.7z.002
Now multi-volume "raw.7z.*" archive contains good headers from raw.7z and compressed data from "bad.7z"
We press "Extract" for raw.7z.001 file. It will extract raw.dat file and probably it will show "Data Error" message.
Now we have raw.dat file that contains recovered stream from bad.7z.
Most of 7z archives are solid. If bad.7z archive was solid, then recovered stream consists of concatenated original files
If bad.7z archive is not solid, then recovered stream contains data for one file. It can also contain some garbage data at the end.
No we must use some parser software that will look raw.dat, search file signatures and extract some files from that file.
You can try to use parser from 7-Zip.
You need 7-Zip 19.00 or later version.
Select raw.dat and call context menu command "7-Zip > Open Archive > #"
It shows:
1.bz2 2.readme.txt.gz 3.zip 4 5.xz
Press Extract command to extract these files.
So we have recovered some of the original files, but without original names.
7-Zip parser can find archives in raw file. But it doesn't recognize another files, like xml, html, jpg, png files and so on. So probably you need some another parser software to extract files from raw file.
If there are more than one solid block in 7z archive, you must detect exact end of solid block, and start of next solid block.
The recovering procedure for that case will be described in future