Could not open as archive 7z files.

  • Roman

    Roman - 2014-07-06


    I have about 20 files created by Cobian backup day by day and I can not open all of it because 7z return "Error: Can not open file as archive." Thank You for Your procedure for recovery raw data, but it does not work in my case and I don't know why. Could You please take a look to first 48 and last 128 bytes of my bad archive and tell what the problem with it?
    Size of archives is about 12GB each. I tried recovery procedure with full bad archive and with 2GB part of it, but result was the same.

    I tried to cut first 2GB of bad archive and recovery raw data, but it does not work too.
    I take 2GB part of bad.7z archive and cut first 32 bytes of it
    bad.7z.001 (32 bytes)
    bad.7z.002 (1 999 999 968 bytes)
    Then I add to good.7z RAW file (size 2 812 376 359 bytes) and cut first 32 byte, part with size of bad.7z.002 and remainder:
    good.7z.001 (32 bytes)
    good.7z.002 (1 999 999 968 bytes)
    good.7z.003 (721 412 729 bytes)
    Then I renamed bad.7z.002 to good.7z.002 and tried to open good.7z.001 and I saw RAW file in it, but "Error : Data Error" occured when I tried to extract RAW file.
    Please help me detect the problem.

    First 48 bytes:
    000000 37 7a bc af 27 1c 00 02 00 00 00 00 00 00 00 00
    000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    000020 00 68 33 be 1c 86 30 77 60 f4 a4 84 2a 40 0c 1c

    Last 128 bytes:
    000000 e8 00 79 05 f4 36 91 ba fe b6 f1 a3 04 cc 68 bf
    000010 31 5b 3a b9 4a 1f 8d 2f 0e d2 e8 f0 2c 72 8e fa
    000020 97 d2 92 7b 6b 5f 6a aa 05 fb ed 7c 9b 90 44 93
    000030 b8 58 3d 6f 9c ce d4 61 ff 93 81 57 e6 91 a1 83
    000040 f4 c9 cb 3b 96 fb f1 cb 7a 7a 30 81 89 0a 1f 0d
    000050 1b 2f fb 04 9c 3d a0 ff 07 0b f7 8c 7f fd 7f eb
    000060 2d e0 f8 32 3f 53 f9 3c 9d 73 c2 48 87 65 89 fe
    000070 01 51 09 1a ed ea e7 4a c6 a4 7f 02 00 54 39 00

    Thank you beforehand.

  • Igor Pavlov

    Igor Pavlov - 2014-07-06

    Probably you use LZMA compression method in bad.7z.
    And you must use same compression method (LZMA) in good.7z

  • Roman

    Roman - 2014-07-06

    Thank You for answer.

    I used LZMA compression in good.7z too. For reasons of clarity I used the same Cobian backup to make good.7z from RAW file with the same parameters. RAW file extracted from good.7z, but bad.7z.001 not. May be solid block is smaller than 2GB, how can I detect solid block size, is it possible?

    And what about the last 128 bytes of the bad archive, what happened with archives? How it happend, that more than 20 archives doesn't open but hardware is good.

    Thank You for Your attention.

  • Igor Pavlov

    Igor Pavlov - 2014-07-06

    There is no "end header" and there is no link to "end header" in "start header".
    It means that a creation was interrupted.

    When you have "Error : Data Error", do you have any data extracted to RAW file?

    • May be solid block is smaller than 2GB, how can I detect solid block size, is it possible?

    You must think about it, only if you have any data in RAW.

    Last edit: Igor Pavlov 2014-07-06
  • Roman

    Roman - 2014-07-06

    Thank You for Your attention.

    There are no data in RAW file after extraction. And the error comes right after I try to do extract from the archive. Several times I issued a message "bad crc", when I tried to do a recovery procedure with the entire archive rather than 2GB, but in RAW file did not have data too. In what cases, the procedure proposed by You can not work at all?
    For example, if the archive was protected by password, can recovery procedure still works? Perhaps the archive was protected by password.

    Thank You beforehand.

    Last edit: Roman 2014-07-07
  • Igor Pavlov

    Igor Pavlov - 2014-07-07

    1) show information from "good" similar 7z archive, created by Cobian:
    7z l good.7z -slt > list.txt

    2) remove end of some "good" archive (the archive must be larger than 50 MB). And try to recover data with procedure.

  • Roman

    Roman - 2014-07-07

    Thank You for helping me.

    1. Here is information from similar good archive one year old.
      7z l good.7z -slt > list.txt
      See attached file.

    2. I took one year old archive, from which I generated list.txt and cut first 32 bytes and 1GB from it.

    Next I took RAW (size about 78 GB) file and added it to good.7z (with 7-zip 9.34 and Ultra compression LZMA:26), next I cut first 32 bytes from it, 1GB and took remainder:
    If I tried to open good.7z.001 all worked fine, but when I changed good.7z.002 with bad.7z.002, I reveived error "Data corrupted".

    May be it because there are folders in bad archive? There is only one folder in the top of archive's tree and no files. All files are in subfolders.

    Thank You very much.

  • Igor Pavlov

    Igor Pavlov - 2014-07-07

    OK. That archive is non-solid. So it's more difficult to recover data.
    Maybe you must change source code (LZMA decoder).
    There are some states in LZMA decoder than can show the end of LZMA stream with big probability.

    In any case you have no names of files.
    And if the number of files is big, it can be difficult for you to recover name for each file.

  • Roman

    Roman - 2014-07-07

    Ok, I see. Thank You, in any case.

    I need only one file from the archive, it has size about 1GB and has a specific header.
    Is there any procedure to find stream for such parameters in non-solid archive. Do You have any advice for me? I would be very grateful.
    Or may be You know humans who can do such recovery for fee?
    If no, is there the detailed information about 7z and LZMA except
    You, sir, are my last chance to save important data.

    Thank You very much for Your attention.

  • Igor Pavlov

    Igor Pavlov - 2014-07-08

    You can write software that will try each position in archive as start of new lzma stream.
    First byte of LZMA stream is 0.
    But there is still problem to detect the end of lzma stream.
    As I wrote you must change source code for that task.
    To detect the end of stream you also can look to next byte.
    If it's 0, probably it's real end of stream.

  • Roman

    Roman - 2014-07-08

    I am very grateful for Your help.

    I happened to recover what I wanted.

    Fortunately, all the files that I was looking, had contained identical 10-byte header at the begining.
    With help of 7zip I just archived similar good file and took 10 byte header from it after compression. 10 byte's header was the same in all files. Then i just cut the BLOCKS from bad archive, which start at those 10 byte and about 500MB in size(because any important file in bad archive compressed with lzma is smaller then 500MB). Then I made files(block001.lzma .... block00N.lzma) with LZMA header:
    5D 00 00 40 00 FF FF FF FF FF FF FF FF
    and one of BLOCKS in each file.
    5D - LZMA properties
    00 00 40 00 - dictionary size 2^22 in my case
    FF FF FF FF FF FF FF FF - mean that uncompressed size of the stream is unknown

    Next i did:
    lzma.exe d block001.lzma important1.file -d22
    lzma.exe d block002.lzma important2.file -d22
    lzma.exe d block00N.lzma importantN.file -d22

    In lzma-file-format.txt from xz archiver's source code I read "For example, the command line tools from LZMA Utils and LZMA SDK silently ignore all the data after the first lzma stream. In contrast, the command line tool from XZ Utils considers the lzma file to be corrupt if there is data after the first lzma stream."

    Therefore in my case lzma.exe read first stream and decode my important files and threw everything else.

    Thank You, Igor, for Your attention, advices and for powerfull utils and software.

    Last edit: Roman 2014-07-08
  • Roman

    Roman - 2014-07-09

    Sorry, I was wrong. Use of FF FF FF FF FF FF FF FF in LZMA header not always give good results.
    Better way is to specify uncompressed file size, if You know it.
    Using FF FF FF FF FF FF FF FF in LZMA header I got important file without some kilobytes at the end after encoding( I don't know why). But I took size of important file from its header. Next I changed FF FF FF FF FF FF FF FF to size of important file in little endian and decode again.

    Last edit: Roman 2014-07-10

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks