I have a multipart .rar archive containing a single .tar.gz file inside it (don't ask why, that is just how it was made). I am missing a few of the parts, but do have the first part. I would like to extract as much of the .tar.gz as possible. How can I do that?

If I run unrar x -kb file.part1.rar it always extracts the beginning of the .tar.gz from part1 and stops there with an error. I am happy to try any tools (doesn't have to be unrar).

  • 1
    obviously, you need the whole thing, its not going to work otherwise – Sickest Jan 30 '14 at 23:23
  • 1
    Well, he does say he wants "as much as possible". However, it is highly likely that whatever he extracts will not be usable, unless it's a simple file format (bitmap?). – WindowsEscapist Jan 30 '14 at 23:37
  • If there's another archive inside which contains many files, he might be able to recover some of the files. The trick is just to make WinRar extract as much as possible. – davidbaumann Jan 30 '14 at 23:43
  • I don't understand why people vote down questions, just because they don't understand. – davidbaumann Jan 30 '14 at 23:43
  • So did you find a solution, and share with us? – davidbaumann Dec 7 '15 at 20:00
up vote 2 down vote accepted

I had a similar thing on windows, when I had parts 1,5,6,9,10 out of 10. I was missing parts 2,3,4,7,8.

  1. use 7zip to extract the parts you have, and rename them accordingly. i.e.: pt1 pt5 pt6, etc.

  2. generate null (zero) file to fill the missing parts, using the exact size in bytes of each of the parts you DO have and extracted (i.e. size of pt1 which is the same as the size of pt5 and pt6...):

    fsutil file createnew [path_to_file] [size_in_bytes]

    in my case I used:

    fsutil file createnew C:\TMP\empty 1022701562

  3. concatenate the files (using the /b for binary files)

    copy /b file1+file2+file3 targetfile

    in my case:

    copy /b pt1+empty+empty+empty+pt5+pt6+empty+empty+pt9+pt10 output_file

when it was done, I loaded the file in Deluge bittorrent client, and forced recheck, and I was only missing the percentage that I really didn't have, meaning the bittorrent client identified that I do have the true information between all the zeros I added.

This is probably not relevant anymore, but I just had the same problem and found a simple solution that worked for me and thought it would be nice to share.

I had a password protected RAR archive in 6 parts, but part4 was missing. I tried to use WinRAR's "repair" function but it said it couldn't find the recovery record. I tried the methods above but they didn't work and the extraction always stopped where the missing part started.

Finally, I decided to fool WinRAR into thinking parts 5 and 6 where a different archive and renamed them as "archive.part1.rar" and "archive.part2.rar". I then told WinRAR to extract the new part 1 and even though I got an error message saying it couldn't extract the file that ended at the beginning of the new part 1 (as it was missing some data from the missing part 4), it managed to extract all the other files from the original parts 5 and 6.

I hope this will help other people with the same problem in the future.

I assume 100Mb parts, part 3 missing. You can try

cat blubb.part01.rar blubb.part02.rar blubb.part04.rar > blubb.rar

also I would try, which might work better and make WinRar think, the file is corrupted:

dd if=/dev/zero of=blubb.part03.rar bs=1M count=100
cat blubb.part01.rar blubb.part02.rar blubb.part03.rar blubb.part04.rar > blubb.rar
  • Good ideas, tried them out. 1. If all existing parts are concatenated, unrar fails (CRC error) at the exact same place. 2. If I just copy a later part to have the same name as the missing part, it fails at the same place, but then prints messages that imply it is processing the later parts (maybe looking for the start of another file) 3. If I create an all-zeros file with dd, it fails with "Bad archive" – Alex I Jan 31 '14 at 2:17
  • And, if I create an all zeros file and concatenate, it fails at the same place with "Cannot find volume" – Alex I Jan 31 '14 at 2:19
  • Just thinking: cat blubb.rar | unrar > file.tgz. – davidbaumann Jan 31 '14 at 2:28
  • Maybe you want to use WinRar for Windows – davidbaumann Jan 31 '14 at 2:29

Step 1: Rename the files, for example:

file.part1.rar -> fileA.rar
file.part2.rar -> fileB.rar
file.part3.rar -> fileC.rar
etc..

Step 2: Use 7-Zip to extract each file.

Profit!

(In some circumstances, renaming is unnecessary and you can let 7-Zip extract all files for you.)

  • 3
    This is not going to help with files that span more than one part file. – Rohit Gupta Oct 18 '15 at 5:57
  • Have you tried to extract each renamed file one by one using 7-Zip? – cychoi Oct 18 '15 at 12:47

I had only the second part of two part rar archive, while unpacking part 2 as expected winrar popped a message saying the first part was missing; I also noticed that the full content of part two had been unpacked in the folder; so without touching winrar's popup message, I copied the unpacked files into another folder and then clicked on close in the winrar's popup message; the unpacked contents were deleted by winrar, but since I had copied them earlier into a different folder, I could use the unpacked content from that different folder.

7-zip will extract the part of a file from a multi-part rar, and then you can stitch them back together with dd. For example, if you have the first and last rar-parts:

7z x p1.rar
mv dir p1  # rename out of the way
7z x plast.rar
unrar l p1.rar
   # note the file size of the entire file
ls -l dir/file  # note the size of the last part
dd if=dir/file of=p1/file  conv=notrunc  bs=1 seek=$((full_size - lastpart_size))

If the offset you need to seek to isn't prime, then use a block size larger than one. dd can only seek to multiples of the output block size. dd really does make read and write system calls with that block size, so bs=1 really sucks.

A large ibs (input block size) would save half the CPU time, since seek is in units of obs (output block size). Or maybe there's some other tool which can seek to an arbitrary byte position and then do normal-sized I/Os. Or if you were scripting this, you could dd with bs=1 up to 32k-aligned, then maybe tail -c +$misalignment lastpart/file | dd ... of=p1/file conv=notrunc bs=32k seek=$(( (full_size - lastpart_size + misalignment) / (32 * 1024) ))

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.