file open -> disk full -> save -> file 0 byte

[Stephen Samuel]

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


On Fri, Oct 8, 2010 at 6:10 AM, Bodo Thiesen <bothie at gmx.de> wrote:

> * Ralf Gross <Ralf-Lists at ralfgross.de> hat geschrieben:
>
> > ~ # ext3grep /dev/sda6 --inode 145601
> > size: 175659
> > sectors: 352 (--> 1 indirect block).
> > 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.
>
> *** 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
>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users at redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users
>



-- 
Stephen Samuel http://www.bcgreen.com  Software, like love,
778-861-7641                              grows when you give it away
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20101008/9e91f395/attachment.htm>