How to extract multipart rar with missing parts?

Question

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).

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.)

Answer 5

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.

Answer 6

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) ))