I googled "mount segmented dd image" and this was the first hit.<br><br><a href="http://davnads.blogspot.com/2009/11/linux-mount-split-dd-file-images.html">http://davnads.blogspot.com/2009/11/linux-mount-split-dd-file-images.html</a><br>
<br>I think there are other ways, but the key is to use multiple losetup commands to access your segments. <br><br>Good Luck<br>Greg<br><br><div class="gmail_quote">On Wed, Oct 6, 2010 at 10:43 AM, Michael B. Trausch <span dir="ltr"><<a href="mailto:mike@trausch.us">mike@trausch.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hey everyone,<br>
<br>
I have an interesting little problem.<br>
<br>
I was doing a backup of someone's hard disk drive in their laptop<br>
computer, and the first time I ran dd it failed (albeit on an even block<br>
boundary). So I ran the dd command again, skipping all the sectors that<br>
were already copied, and put that in a second file.<br>
<br>
Now, I have two very large files that have the HDD image in them. What<br>
I want to do is combine them into one file. I want to do this<br>
efficiently, though; the normal "cat hdd-* > hdd-full.img" method will<br>
take hours and hours, and I don't want that.<br>
<br>
I'm using btrfs, and I thought that maybe there would be some way that I<br>
could create a file that would have two extents, mapping to the first<br>
image and second image, so that I can mount the image loopback and begin<br>
extracting files. But I can not find a way to do that --- The way that<br>
I'd expect it to be done in btrfs would be to treat the files as<br>
“ropes” (á la strings) and be able to efficiently and logically put the<br>
ropes together. I seem to be barking up the wrong tree there, though.<br>
<br>
Is there something out there that would permit me to solve this problem<br>
in an efficient way without actually cat'ing the files together? I<br>
don't want to double the disk space used by this even temporarily since<br>
that would put me, well, pretty much over-full. :-) I could write a<br>
program that created a large sparse file and filled the sparse file<br>
block-by-block, effectively moving chunks from one file to the other,<br>
but that, too, would take hours to do and if the power went out, I'd be<br>
in a pretty un-happy state.<br>
<br>
--- Mike<br>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Greg Freemyer<br>Head of EDD Tape Extraction and Processing team<br>Litigation Triage Solutions Specialist<br><a href="http://www.linkedin.com/in/gregfreemyer">http://www.linkedin.com/in/gregfreemyer</a><br>
CNN/TruTV Aired Forensic Imaging Demo -<br> <a href="http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/">http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/</a><br>
<br>The Norcross Group<br>The Intersection of Evidence & Technology<br><a href="http://www.norcrossgroup.com">http://www.norcrossgroup.com</a><br>