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

[Bodo Thiesen]

* 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