[SOLVED] gparted crashed during resizing

Gedakc,
Thank you for your reply!  I was using the current live CD.  Gparted v 0.15.0 with testdisk 6.13.  I have a couple other rescue CDs, so I may have used the testdisk from one of them before, so it may have been a different version.  I'll look for another drive to dd to.  Do you have any suggestions as to what to check for?
Thanks!
p

I was moving the left boundary to the right by 100M.  How would one guess? Do you think it stopped during shrinking or moving?
Thanks!
p

Thanks, gedakc.  Can you think of a way to figure out where exactly it crashed and more importantly some way to restore the data?

Thanks, gedakc!
Are there any tools to help me follow the first approach?  Until this moment in my life I lived blissfully unaware of the internals of filesystems   Some of the files that I need to recover the most are python files.  I'll give photorec try, though I cannot imagine it would be able to handle those.
p

Given the 100M move, do we know exactly by how many sectors was gparted moving the partition? I believe the block size is 4k in my case. does it align by block size?  I tries photorec and it does not recover what I need. I can figure out an approximate inode number where the file system was being moved.  I guess if I can find the location of the 100M that repeats itself, I'm done?  The question is how
p

Thanks, gedakc, it helps a little, but I am more interested to know what would be the exact number of bytes by which gparted would have been moving the tail (or some way to find it out).  I noticed that istat from sleuthkit starts giving me errors beginning from block group 1344.  I copied groups 1344 and 1345 into a file and was fiddling with it until I found that up until file offset of 0x3f9c335 I have a portion of a large csv data file, then 0xA271AAB of zeros and at e20dde0 data continues.  It looks like gparted overwrites the destination with zeros before writing?  I tried a string search of the fragment before zeros within the tail of the file and had no luck.  Does this behavior make sense to you?  The block of zeros seems odd to me and the size of it is also larger than I would have expected.  For 100M resize I would have expected something like 0x6400000 fie system move, or no?  Can you please shed some more light on what is going on here?
thx,
p

I'm updating this for the benefit of others, as I was able to restore my disk after learning more about ext2/3/4 file systems.  The tools I used were sleuthkit on Caine live CD and python.  Specifically, fsstat reports some useful summary information about block groups, including inode ranges and inode table locations.  Using the inode ranges from fsstat we can get additional information by looking at some random inodes by hand with istat <inote number>.  By doing this I noticed that inodes starting from block group 1344 (inodes > 11010048) give errors.  The relevant part of the fsstat output is:

This tells us that the inode table in this part was already moved, while the previous one is still intact.  Realizing that I need to look for the break between blocks 43524128 and 44040224, and knowing that my move was approximately 100M I was able to narrow the search with the following python code:

sda2 = open("/dev/sda2","r")
block = 43524128
size =0x1000

for n in range(30):
    sda2.seek((block+20000*n)*size)
    dump = sda2.read(40000*size)
    offset = dump.rfind(dump[:100])
    print offset
    if(offset>0):
        print block+20000*n,'>',offset,'>',dump[:20], dump[:20].encode("hex")

Basically, we are looking for ~100M that repeats itself.  Luckily for me there was something unique there to find a match.  I had to narrow the location with further scripts and double check by hand.  After this I was able to reverse the move and mount the filesystem.  This is probably not the optimum way to get there, but the optimum would have been to back up my data in the first place I hope this write up is not needed by anybody...
p