[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

a slightly easier way of going through the indirect block...
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

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 gmx de> wrote:
* Ralf Gross <Ralf-Lists 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. ;)


#! /bin/sh

# 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.


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 redhat com

Stephen Samuel http://www.bcgreen.com  Software, like love,
778-861-7641                              grows when you give it away

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]