What happened
Originally written Oct 17 2018:If you are like most you probably move files from a SD card to a hard disk for processing instead of copying first and then deleting. Generally that saves time but then ever so often something happens like it did to me last weekend when between files one and two I received the error the SD could not be read. Seems the delete of the first file took out the partition somehow. It is still unclear if it was a SD card issue or a glitch on the PC / card reader side. Though I'm leaning toward the card. On principal (gut feelings) if nothing else.
What did not work
My first thought was to run SpinRite on it to try and sort any dead sectors but in this case SpinRite just hung discovering devices. I first assumed this was the corrupted partition causing an issue but even after formatting the SD card, SpinRite still hung discovering devices. Further research points to this being a known issue with some USB devices.A little Googling will tell you the best way to sort this is to run PhotoRec which will scan the card and reconstruct the files for you. Note the source is on Github but get from the CGSecurity site. But this seems not to actually work or at least not for me. (What did comes later.) I was trying to retrieve files from a Canon G30 camera in this case which might have made a diff but I doubt it. It records in the usual 4 GB mp4 format files mike a lot of cameras do.
I tired various combos of file types to scan for but the best I could get was a mix of mp4s and movs, none of which were playable. Then I found a post that said there was more info in the TestDisk Documentation. (PhotoRec is part of the TestDisk package.) On page 45 it says to
type file2_ftyp.mov file1_mdat.mov > test.mov
But I did not have any _ftyp.mov files in my recovered files. I tried using some mp4 and _mdat.mov files that looked like they should match but no luck. Note this insanely slow. After I was able to recover the files I revisited this to try and reverse engineer. After having it recover anything looking like a file (default file type options) I looked for what might match one of the short files that was 3,833,076,414 bytes.
The nearest matching mov files were 3,731,881,984 a diff of 101,194,430 bytes and 3,832,158,910 bytes a diff of 917,504 bytes. The mp4 files created by the tool are 917,504 bytes. So the second one seems right but does not play and thinks it is the same 16 minutes long as the recovered mp4. This got me thinking digging deeper into the properties of those mp4. None of them matched the run time or data rate of the recovered file. A couple had no info though.
So then I thought what about taking the mov file size, add 917,504 and then find the matching sized recovered file. But that did not work either because adding that to any of the full sized movs makes them larger than the mp4s they should become. Finally I made a sheet to cross ref all the data to make one last try of getting at least one of the recovered from the pieces in case I need to some day. That seems to say this should work
type f24968960.mp4 f73957376_mdat.mov > 3.mp4
And it seems to! So basically if you end up going this way what you need to do is try all 12 mp4 with each of 14 mov files. That is 168 combos. You might be able to cut that down a bit with some guessing. Here one of the movs was obviously too small and I was able to guess at a couple by looking at mp4 run times vs mov sizes. (See the sheet.) Then by trying all possible combos I was able to get 4 more. If you have the space (about 750 GB to recover this 43 GB of files) and can run while doing something else, like sleeping, your quickest option is to create a matrix like I did in the sheet, copy those commands to a bat file and let it run. Then once it is done you can quickly try and open each one to see if it works.
Bottom line though I was still only able to recover 8 of the 12 files which is not very good. Note too I did "find everything" runs on Linux and Windows and got diff results! (See sheet.) The run using the Windows GUI recovered 2 each less mov and mp4 files. 2 of which matched up in the Linux run.
Note the instructions tell you to upload a file to their site if you can't get it to recover your files correctly and it will try and give you hints to tweak the scan. Problem is the max is 10 MB which in this case is less than 2 seconds of video. Not encouraging plus meant I needed to record something short onto another card to even have a sample. I tried it anyway with an 6.53 MB (< 1 second) file and it said was still too large.
Trying to rebuild partition instead
After I gave up on recovering the files the first time I started thinking maybe I could recreate the partition and maybe I could then recover the files with some other tools. Starting on page 31 of the TestDisk Documentation it gives you some basic instructions. At first I cloned the SD card to an image file and tried options to recreate the partition which did not seem to work. Then I noticed I could list the files and things fell into place. Here are the steps that worked for me.Select the image or disk to work on Note can give file or device path on the command line as I did here in which case only that one will show.
You probably want to select Intel here. If the partition is toast it come up with None highlighted.
Select Analyse
Which gets you this screen but in this case is unhelpful so select Quick Search
Now it gives you its best guess at what the partition was. Note the type names seem a bit fluid. Just try what it gives you first. Type P, if you do not get a list of files on the next screen backup and use T on this screen to try something else.
You should now see the top folder on the card. Select your way down the tree till you get to the files you want.
Type h to hide old deleted files if they are not ones you want.
Select each file by typing : (the colon key) on while it is highlighted
Once you have all the ones in this folder you want selected type C. Note that is a capital C. Else where case does not matter but on this screen it does.
Select your way to the folder you want the files to be copied to on your hard drive and type C. Note the path of the file on the SD will be recreated under this folder. For instance with the above, I select E:\out so the files will end up in E:\out\ DCIM\124_1005.
Unless you want files from other folders on this SD, that is it. Just Cntrl-C to exit or Q your way back through all the menus.
Update:9/6/2019
Noticing this never was published. Cleaned up a bit and doing so now though obviously almost a year later if some bit it missing I would not know. Will update if needed.
