[linux-l] gelöschte Dateien wiederherstellen

[Steffen Schulz]

On 030302 at 15:55, Oswald Buddenhagen wrote:
> On Sun, Mar 02, 2003 at 03:06:47PM +0100, Steffen Schulz wrote:
> > On 030302 at 11:00, Oswald Buddenhagen wrote:
> > 
> > Hab ich mir auch angesehen, aber das gibt mir doch nur die Metadaten.
> >
> ja, die brauchst du ja auch. aus den metadaten errechnest du, wo die
> "datendaten" liegen.

Hm....gut, sehr viel komplizierter scheint das dann nicht mehr zu
werden, vorrausgesetzt ich weiss, wie 510 Inodes innerhalb einer Gruppe
angeordnet sind. Dann kann ich aber kein dls benutzen und muss den Rest
auch selber machen. Da kann ich dann auch gleich nen fs-treiber
schreiben, was zweifellos meinem Wissen zuträglich ist, meine
Eltern aber nur ungern sehen würden. Wenn ich die kommenden Klausuren
und Prüfungen in den Sand setze, den Studienanfang verpasse und die
nächsten zwei bis drei Jahre das Zimmer tags über von der Sonne
abschirme und jede Nacht den Kühlschrank leere...wird ihnen nicht
gefallen, in der Hinsicht sind sie doch ungewöhnlich konservativ...

> eigentlich interessieren dich inodes überhaupt nicht ... die enthalten
> die metadaten die du brauchen würdest, aber die sind ja nun
> überschrieben. folglich ist das einzige, was du über inodes wissen mußt, 
> wo sie liegen (so daß du sie überspringen kannst).

Richtig. Lauter leere von mkfs frisch erstellte Inodes zu filtern, kann
aber nicht ganz so kompliziert sein, die sollten recht einheitlich
aussehen. In der Tat scheinen dort Anfangs einfach nur Zahlenfolgen zu
stehen, der Rest ist dann mit nullen aufgefüllt. Trotzdem sind sie noch
so variabel, wie's nur geht, d.h. der Anfang mit Zahlen ist Teils nur
wenige Bytes lang teils ist der Block fast voll davon...

> > diese Unterbrechungen drin sind(angenommen, es sind(leere, da kein
> > rec-tool was findet) inodes), dann stimmen deren Positionen nicht mehr
> > mit den angaben in den specs überein, weil u.a. Superblöcke von dls
> > rausgeschnitten wurden.
> > 
> und das gefällt mir gar nicht. daß die daten trotz "metadatenfreiheit"
> nicht fortlaufend sind, weist evtl. auf eine andere formatierung hin
> (vielleicht waren das meta-daten "im früheren leben"). vielleicht hat
> der fs-treiber aber einfach nur eine etwas undurchsichtige
> alloziierungsstrategie.

kleiner hexdump:
0000000 1517 0008 1518 0008 1519 0008 151a 0008
0000010 151b 0008 151c 0008 151d 0008 151e 0008
0000020 151f 0008 1520 0008 1521 0008 1522 0008
0000030 1523 0008 1524 0008 1525 0008 1526 0008
0000040 1527 0008 1528 0008 1529 0008 152a 0008
0000050 152b 0008 152c 0008 152d 0008 152e 0008
0000060 152f 0008 1530 0008 1531 0008 1532 0008
0000070 1533 0008 1534 0008 1535 0008 1536 0008
0000080 1537 0008 1538 0008 0000 0000 0000 0000
0000090 0000 0000 0000 0000 0000 0000 0000 0000
[...nullen...]
0001000 <- ende, exakt 4096Byte

Wie man sieht, wird einfach nur ne Zahl hochgezählt.
Vermutlich über die ganze Festplatte hinweg. Irgendwann fangen dann
die Nullen an, warum die mal früher und mal später kommen, k.A.
Sie stehen auch an bestimmten Stellen, haben Anfangs z.B. sehr viele
56k-Dateien erzeugt(inklusive dieser 4096 Byte Müll). Es war
garantiert die selbe Formatierung mit den selben Partitionsgrenzen.

> > Wenn ich nu auf dls verzichte, wird der Aufwand wieder recht gross,
> > dann fang ich nämlich an, anhand des Superblocks  zu rechnen, wo und
> > wie die inodes verteilt sind, wenn ich nen pdf aus obiger Suchanfrage
> > richtig verstehe. Da schreib ich nen halben fs-treiber. Und ich kann
> > kaum programmieren, am besten gehts immernoch per shell :(
> > 
> nun ja, im prinzip willst du das alloziierungsverhalten von linux'
> fs-treiber möglichst genau abbilden - ob du willst oder nicht. ;)

Tja...wenn ich einfach das original-modul manipuliere, bin ich
vielleicht noch dieses Jahr fertig. Dann hab ich zwar kein Abi, kann
aber nach nem Eignungstest bestimmt doch noch ITS studieren...*hm*

mfg
pepe
-- 
pepeatgoofy at gmx.net                           mail -s "get gpg-key"
Key fingerprint: 3F07 5EB1 2D42 E806 51C1  8278 CD3F 4DB3 2187 FF31