a slightly easier way of going through the indirect block... recovered=12 for i in `hexdump -e '4/4 "%10i " "\n"' /ramfs/restored.ind` ; do if [[ "$i" -ne 0 ]] ; then dd if=$DEV bs=$BS of=/ramfs/restored.ind skip=$i seek=$((recovered++)) count=1 fi done However, if the inode in question still exists, then I'd be inclined to suggest that you mount the filesystem (readonly preferably), and then hunt for the inode.... let the filesystem do the heavy lifting for you. find /mount/recovered -inum 145601 -print or, even better yet: cp ` find /mount/recovered -inum 145601 -print` recovered-file <div class="gmail_quote">On Fri, Oct 8, 2010 at 6:10 AM, Bodo Thiesen <<a href="mailto:bothie@gmx.de">bothie@gmx.de</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> * Ralf Gross <<a href="mailto:Ralf-Lists@ralfgross.de">Ralf-Lists@ralfgross.de</a>> hat geschrieben: <div class="im"> > ~ # ext3grep /dev/sda6 --inode 145601 </div>> size: 175659 <div class="im">> sectors: 352 (--> 1 indirect block). </div><div class="im">> Direct Blocks: 325495 325496 325497 325498 325499 325500 325501 325502 325503 325504 325505 325506 > Indirect Block: 325507 > > So I know that there is something left of the file, but I don't know how to get > it back. </div>*** WARNING *** The following code snippet is meant to explain what you could do. Please don't stop using your brain. ;) *** BEGIN SNIPPET *** #! /bin/sh DEV=/dev/sda6 BS=4096 # This may be 2048 or 1024 - whatever cluster size your ext2 # file system uses # Recover the first 12 clusters (the direct clusters) dd if=$DEV bs=$BS of=/ramfs/restored.data skip=325495 count=12 # Get the indirect cluster dd if=$DEV bs=$BS of=/ramfs/restored.ind skip=325507 count=1 # And dump it's content decimally ... hexdump -e '4/4 "%10i " "\n"' /ramfs/restored.ind # you should get an output like # 325508 325509 325510 325511 # 325512 [...] # Check, that the numbers are one bigger than the previous ones. # Recover the following parts of the file (assuming, that the first # number is the 325508 and that there are 5 countiguous numbers. # The 12 comes from the previous skip argument dd if=$DEV bs=$BS of=/ramfs/restored.data skip=325508 seek=12 count=5 # If there is a jump in the numbers printed by hexdump, continue with # the next cluster chain (17 = 12 + 5 - it's just the sum of clustes # already written to the file): dd if=$DEV bs=$BS of=/ramfs/restored.data skip=$whatever_number_comes_now seek=17 count=$length_of_chain # Repeat the last step until you are done. *** END SNIPPET *** After you are done, check the file and then copy it over to the file system so your user can continue to work on it again. And tell that user that he should stop using the application he was using all together. Overwriting a file with updated content is not state of the art for at least two decades. The old file content has to be saved in a backup file first or the old file could just be renamed. Every software I use does it either way. This way your user wouldn't have had this problem in the first place (just take the backup file and throw away the last 20 minutes of work - recovery takes longer anyways ...). Alternatively: Think about a proper daily (or even hourly) backup plan. Regards, Bodo <div><div></div><div class="h5"> _______________________________________________ Ext3-users mailing list <a href="mailto:Ext3-users@redhat.com">Ext3-users@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/ext3-users" target="_blank">https://www.redhat.com/mailman/listinfo/ext3-users</a> </div></div></blockquote></div> -- Stephen Samuel <a href="http://www.bcgreen.com">http://www.bcgreen.com</a> Software, like love, 778-861-7641 grows when you give it away