There is a dedicated "Help" forum, but since you have already started the topic here - let's go. Please, describe your problem: type of archive, error messages you get.
Last edit: Shell 2015-05-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As we know 7z file of archive format is used for storing compressed files and sometime creates frustrating time for its users at the time when they unable to open the 7z file. There will be lots of techniques available on the internet which help to repair the corrupt 7z file. Below post help you to know how to deal with with corrupt 7z file.
I archived some files using the 9.20 version four weeks ago. Most of the files were xlsx, txt, pdf, and doc. I used a long password to secure them. Four days later the archive refused to extract with the error message "Can not open file 'a.7z' as archive".
The first three rows (48 bytes?) from the hex reading of the file are:
as are several hundred following rows. This does not look right.
The last four rows (96 bytes?)are
17 06 E9 D0 5E 6E 01 09 A6 C0 00 07 0B 01 00 02
24 06 F1 07 01 0A 53 07 74 CD 7D B2 92 2E 5F 1E
23 03 01 01 05 5D 00 C0 00 00 01 00 0C A6 BB C0
D2 BB 0A 01 37 D6 4D 62 00 00
The archive is 154,530 KB in size. Unfortunately I have shredded the original source files.
I tried to make sense of the discussion on the forum but could not. I am not conversant in security and compression matters.
The archive contains more than ten years of my personal notes and loosing these would be very sad for me. I would greatly appreciate any help that I might get.
Regards.
slowjeremy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In your case:
1) start of archive is incorrect
2) end of archive probably is correct
Probably it's difficult to recover the data, if it was "solid" archive.
You can try to recover the list of files at first.
Replace first 32 bytes with correct header:
8 bytes of 7z header and 24 bytes of zeros. And try to open that archive.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Judging by the start of archive, some of your files are already lost. I think it is hardware fault. What medium is it - HDD, SSD? There is a risk of losing other files, so I suggest to back up the most important of them immediately.
P.S. Have you ever successfully opened or tested your archive?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I manually changed the hex values in the first two rows, which had 16 pairs of characters in each, and on entering the password, the program returned a list of files which seems about right in its length and has the format '(Item number) Data error : Wrong password? : path/filename.***' for every file. The second row or item reads : Warnings: Headers Error. The filenames and extensions appear right. The compressed and uncompressed sizes of the archive appear right. However, I could not trace any extracted file in its original form in the nominated subdirectory on the file explorer.
I do not know how to tell if it was a "solid" archive. The medium was (a partition/ volume of) the HDD. I checked the volume for errors (chkdsk utility? from My Computer menu) yesterday and found none. I had neither tested the archive nor opened it after creating it. While I had created the archive in version 9.20, I used 7-Zip 9.38 beta version to get the extraction results described above today.
I have already backed up other data from all the partitions of the HDD.
Regards.
slowjeremy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is a correction to my message posted about an hour ago.
Unlike what I had said "I could not trace any extracted file ..." before, the extracted files have all appeared on the file explorer now but they are all 0 KB in size and none can be opened.
Sorry about missing this point before.
Thanks.
slowjeremy.
PS: I use Windows XP, if that makes any difference.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To recover that archive you need to replace these "55" bytes with correct values.
You need 2 things:
1) 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.
2) you need to modify 7-Zip source code, so it will use IV for AES from bad archive instead of random value for IV when you create new archive. Only in that case you can recover exact data of original archive.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Check your HDD's S.M.A.R.T. values, especially raw value of reallocated sector count. It should be zero for a healthy drive, big value indicates severe problems.
Look at the "Block" column in 7-Zip File Manager. Solid mode puts several files in a single block and compresses it as a single file; when you lose some data, it is impossible (for ordinary users - Igor's method requires certain qualification) to extract any file from that point to the end of the block. That is, if all of your files are in block 0, then the chances for recovery are very low.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think that it's impossible for ordinary users.
It can be difficult, but possible.
You need:
1) read http://www.7-zip.org/recover.html
2) follow all steps for "example" case from that page for better understanding.
3) recover real data
then the chances for recovery are very low.
If you have another copies of original files that are stored at start of archive, the chance to recover is big, if only small part of file is corrupted.
But in any case you need to hack 7-Zip source code to use IV for AES from bad archive.
If archive is not encrypted, the recovering is simpler.
Last edit: Igor Pavlov 2015-05-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The archive was created with the Solid Block Size field value of 2 GB, which I think was the default value. Does that make it the "Solid" mode? If not, do I have other options for recovering the files?
Thanks.
slowjeremy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can open archive, press "Info" button and look "Blocks" value. Block=1 means that archive has one solid block. So you need to recover corrupted data at start of archive (starting from offset 32). Look also "Method" property. Is it "LZMA 7zAES" method?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On pressing the info button in 7-Zip File Manager, the program brings up the Properties dialogue box in respect of whichever file or folder that is highlighted. I am unable to see any "Blocks" field to read the value we want, on any tab in the dialogue box. What could I be missing?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry about my ignorance, but unless a file or folder is highlighted, pressing the Info button produces no result. I tried the procedure after opening the archive afresh.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not quite sure what your question is. If you mean an 'opened archive' by an open archive, my experience is as described above. I ran the program (to open the archive) again only to make sure I was pressing the Info button in the correct order. If there is a specific difference, I would like to educate myself. Please feel free to respond at your leisure, I can wait. Regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jeremy, can you enter the archive itself? Once in File Manager, put a cursor onto it and hit Enter (or Ctrl+PgDn). You should see archived files then - you told above you had already seen them. Now press "Info".
You can also inspect the "Block" column (it is usually located right after "Method") - the maximal number in it is the number of blocks minus one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your patience and sorry about being so dumb. I am trying to work out your suggestions. I will let you know immediately as I make some headway. Regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I take it that now I should follow the instructions contained in document http://www.7-zip.org/recover.html. Should I be using the source code for version 9.20 or 9.38, given that the corrupt archive was made with 9.20?
Cheers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Look archive in hex editor and try to detect the size of corrupted part (the number of bad bytes '55')
2) call
7z l a.7z > list.txt
and try to find exact copies of first files from list.txt.
If you recreate another "good" version of 7z archive, you need archive from same version (9.20), same settings, same dictionary size (total size of files must be more than 16 MB in your case).
In any case you need modified 7-Zip.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All bytes from offset 00000000 to 021EFFF0 (inclusive; in HxD) are 55. The first good offset is 021F0000.
When I did (called?) '7z l a.7z > list.txt' in command prompt mode, a list of files appeared. If 7 zip encrypted/ archived the files in the corrupt folder in the same order in which the file names appeared on the command prompt screen, then the files occurring at the start of the listing are the ones which have become corrupt. I do not have unencrypted/ good copies of any of these files; except perhaps one or two which I can attempt to build from scratch and hope they would be identical to the original ones. Do I have any hope of recovering the archive or any of the files? Are you or would anyone else using these forums be aware of any tools/ little tricks that might help?
slowjeremy.
NB: Following the advice from the forum, I have manually changed the bytes in the first two offsets to
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
to make the archive show the file names.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi guys,
I am new to this site and a new 7z user. Am I OK to create a topic here to seek help on an archive corruption problem that I am facing with 7z?
Thank you.
slowjeremy.
There is a dedicated "Help" forum, but since you have already started the topic here - let's go. Please, describe your problem: type of archive, error messages you get.
Last edit: Shell 2015-05-20
As we know 7z file of archive format is used for storing compressed files and sometime creates frustrating time for its users at the time when they unable to open the 7z file. There will be lots of techniques available on the internet which help to repair the corrupt 7z file. Below post help you to know how to deal with with corrupt 7z file.
http://recoveryandmanagement.com/2014/09/16/repair-corrupted-zip-rar-tar-gz-7z-in-windows/
Shell
Thank you for responding.
I archived some files using the 9.20 version four weeks ago. Most of the files were xlsx, txt, pdf, and doc. I used a long password to secure them. Four days later the archive refused to extract with the error message "Can not open file 'a.7z' as archive".
The first three rows (48 bytes?) from the hex reading of the file are:
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
as are several hundred following rows. This does not look right.
The last four rows (96 bytes?)are
17 06 E9 D0 5E 6E 01 09 A6 C0 00 07 0B 01 00 02
24 06 F1 07 01 0A 53 07 74 CD 7D B2 92 2E 5F 1E
23 03 01 01 05 5D 00 C0 00 00 01 00 0C A6 BB C0
D2 BB 0A 01 37 D6 4D 62 00 00
The archive is 154,530 KB in size. Unfortunately I have shredded the original source files.
I tried to make sense of the discussion on the forum but could not. I am not conversant in security and compression matters.
The archive contains more than ten years of my personal notes and loosing these would be very sad for me. I would greatly appreciate any help that I might get.
Regards.
slowjeremy.
Read
http://www.7-zip.org/recover.html
In your case:
1) start of archive is incorrect
2) end of archive probably is correct
Probably it's difficult to recover the data, if it was "solid" archive.
You can try to recover the list of files at first.
Replace first 32 bytes with correct header:
8 bytes of 7z header and 24 bytes of zeros. And try to open that archive.
Judging by the start of archive, some of your files are already lost. I think it is hardware fault. What medium is it - HDD, SSD? There is a risk of losing other files, so I suggest to back up the most important of them immediately.
P.S. Have you ever successfully opened or tested your archive?
Igor and Shell
Many thanks for getting back.
I manually changed the hex values in the first two rows, which had 16 pairs of characters in each, and on entering the password, the program returned a list of files which seems about right in its length and has the format '(Item number) Data error : Wrong password? : path/filename.***' for every file. The second row or item reads : Warnings: Headers Error. The filenames and extensions appear right. The compressed and uncompressed sizes of the archive appear right. However, I could not trace any extracted file in its original form in the nominated subdirectory on the file explorer.
I do not know how to tell if it was a "solid" archive. The medium was (a partition/ volume of) the HDD. I checked the volume for errors (chkdsk utility? from My Computer menu) yesterday and found none. I had neither tested the archive nor opened it after creating it. While I had created the archive in version 9.20, I used 7-Zip 9.38 beta version to get the extraction results described above today.
I have already backed up other data from all the partitions of the HDD.
Regards.
slowjeremy.
Igor and Shell
Here is a correction to my message posted about an hour ago.
Unlike what I had said "I could not trace any extracted file ..." before, the extracted files have all appeared on the file explorer now but they are all 0 KB in size and none can be opened.
Sorry about missing this point before.
Thanks.
slowjeremy.
PS: I use Windows XP, if that makes any difference.
To recover that archive you need to replace these "55" bytes with correct values.
You need 2 things:
1) 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.
2) you need to modify 7-Zip source code, so it will use IV for AES from bad archive instead of random value for IV when you create new archive. Only in that case you can recover exact data of original archive.
Check your HDD's S.M.A.R.T. values, especially raw value of reallocated sector count. It should be zero for a healthy drive, big value indicates severe problems.
Look at the "Block" column in 7-Zip File Manager. Solid mode puts several files in a single block and compresses it as a single file; when you lose some data, it is impossible (for ordinary users - Igor's method requires certain qualification) to extract any file from that point to the end of the block. That is, if all of your files are in block 0, then the chances for recovery are very low.
I don't think that it's impossible for ordinary users.
It can be difficult, but possible.
You need:
1) read http://www.7-zip.org/recover.html
2) follow all steps for "example" case from that page for better understanding.
3) recover real data
If you have another copies of original files that are stored at start of archive, the chance to recover is big, if only small part of file is corrupted.
But in any case you need to hack 7-Zip source code to use IV for AES from bad archive.
If archive is not encrypted, the recovering is simpler.
Last edit: Igor Pavlov 2015-05-21
Igor
The archive was created with the Solid Block Size field value of 2 GB, which I think was the default value. Does that make it the "Solid" mode? If not, do I have other options for recovering the files?
Thanks.
slowjeremy.
Shell
I will act on those instructions and get back to you.
Thanks.
slowjeremy.
You can open archive, press "Info" button and look "Blocks" value. Block=1 means that archive has one solid block. So you need to recover corrupted data at start of archive (starting from offset 32). Look also "Method" property. Is it "LZMA 7zAES" method?
Igor
On pressing the info button in 7-Zip File Manager, the program brings up the Properties dialogue box in respect of whichever file or folder that is highlighted. I am unable to see any "Blocks" field to read the value we want, on any tab in the dialogue box. What could I be missing?
1) Open archive
2) Press Info button
Sorry about my ignorance, but unless a file or folder is highlighted, pressing the Info button produces no result. I tried the procedure after opening the archive afresh.
Do you understand the difference between two things:
1) Open (Run) program
2) Open archive
?
Not quite sure what your question is. If you mean an 'opened archive' by an open archive, my experience is as described above. I ran the program (to open the archive) again only to make sure I was pressing the Info button in the correct order. If there is a specific difference, I would like to educate myself. Please feel free to respond at your leisure, I can wait. Regards.
Jeremy, can you enter the archive itself? Once in File Manager, put a cursor onto it and hit
Enter(orCtrl+PgDn). You should see archived files then - you told above you had already seen them. Now press "Info".You can also inspect the "Block" column (it is usually located right after "Method") - the maximal number in it is the number of blocks minus one.
Guys
Thank you for your patience and sorry about being so dumb. I am trying to work out your suggestions. I will let you know immediately as I make some headway. Regards.
Finally, I have managed to do it! The details are as follows:
CRC: 5B41CE0A
Type: 7z
Warnings: Headers Error
Headers size: 10 010
Method: LZMA:24 7zAES
Solid: +
Blocks: 1
I take it that now I should follow the instructions contained in document http://www.7-zip.org/recover.html. Should I be using the source code for version 9.20 or 9.38, given that the corrupt archive was made with 9.20?
Cheers.
1) Look archive in hex editor and try to detect the size of corrupted part (the number of bad bytes '55')
2) call
and try to find exact copies of first files from list.txt.
If you recreate another "good" version of 7z archive, you need archive from same version (9.20), same settings, same dictionary size (total size of files must be more than 16 MB in your case).
In any case you need modified 7-Zip.
Igor
I will follow those instructions and get back to let you know the outcome.
slowjeremy.
Igor
All bytes from offset 00000000 to 021EFFF0 (inclusive; in HxD) are 55. The first good offset is 021F0000.
When I did (called?) '7z l a.7z > list.txt' in command prompt mode, a list of files appeared. If 7 zip encrypted/ archived the files in the corrupt folder in the same order in which the file names appeared on the command prompt screen, then the files occurring at the start of the listing are the ones which have become corrupt. I do not have unencrypted/ good copies of any of these files; except perhaps one or two which I can attempt to build from scratch and hope they would be identical to the original ones. Do I have any hope of recovering the archive or any of the files? Are you or would anyone else using these forums be aware of any tools/ little tricks that might help?
slowjeremy.
NB: Following the advice from the forum, I have manually changed the bytes in the first two offsets to
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
to make the archive show the file names.