|
Ext4magic: Inode - Directory - Journal - Installation - Zeit-Optionen - Tricks&Tipps - Manpage - Expert-Mode |
Durch die Verwendung der Journaldaten hat das Filesystem in ext4magic eine virtuelle Dimension mehr, die Zeit. Dateien und Verzeichnisse existieren nicht von Anbegin und nicht ewig unverändert. Sie können neu angelegt und können gelöscht werden, sie können den Namen und die Größe oder andere Eigenschaften ändern. Auch können neu angelegte Dateien oder Verzeichnisse einen Namen erhalten, der vorher schon von einer anderen Datei benutzt wurde. All diese Veränderungen hinterlassen im Journal Spuren, die ext4magic finden und verarbeiten kann. Durch die Zeitstempel in den Inodekopien kann jetzt ermittelt werden ob die dazugehörige Datei zu einem bestimmten Zeitpunkt existiert hat oder nicht. Beim Aufruf des Kommandos wird mit den Zeitmarken festgelegt, in welcher "Zeitschicht" des Filesystems ext4magic arbeiten soll.
Suchablauf: Suche nach einer Inode für eine gegebene
Inodenummer
zuerst werden alle Inodekopien einer Inodenummer im Journal gesammelt und nach Zeit in eine Liste einsortiert
sind keine Kopien im Journal enthalten, wird die original Inode des Filesystems in die Liste aufgenommen
Diese Inodesammlung wird in der Zeit rückwärts durchsucht
Alle Inode deren ctime größer als "BEFORE" ist, werden nicht verwendet
Die Suche in der Liste wird abgebrochen sobald eine Inode mit einer dtime kleiner als "AFTER" gefunden wird
Die erste so gefundene Inode deren dtime nicht gesetzt ist, wird verarbeitet.
Entspricht keine der Inodekopien den Anforderungen, kann für diese Inodenummer mit diesen Optionen keine Datei recovert werden.
Für eine gelöschte Datei gilt somit, sie wird gefunden,
wenn sie in der Zeit zwischen "AFTER" und "BEFORE"
existiert hat, werden mehrere Inodekopien davon gefunden, dann wird
die ungelöschte Kopie verwendet die den jüngsten Zeitstempel hat,
also "BEFORE" am nächsten liegt.
Für Direktory Inode gilt das gleiche, jedoch wird hier jetzt noch versucht zu der gefundenen Inodekopie auch die passenden Datenblöcke mit den Verzeichnisdaten im Journal zu finden. Ist die Inodekopie erzeugt worden, ohne das sich die Datenblöcke des Verzeichnisses geändert haben, dann wird nach einer Kopie dieses Datenblockes zu einem späteren Zeitpunkt gesucht. Dabei werden auch Datenblöcke gefunden die zeitlich schon hinter "BEFORE" liegen, wird gar keine Kopie dieses Blockes gefunden, dann wird der original Block des Filesystems verwendet, um den Verzeichnisinhalt zu ermitteln.
Somit ergeben sich zwei Möglichkeiten
die "BEFORE" Zeit zu setzen. Entweder sie wird auf eine
Zeit nach dem Löschvorgang gesetzt, oder sie wird so genau wie
möglich unmittelbar vor den Begin der Löschung oder des
Überschreibens von Dateien gesetzt. Im ersten Fall ist die
Ermittlung der "BEFORE" Zeitmarke einfach, und nach einer
größeren Löschung als letzte Aktion im Filesystem kann auch die
aktuelle Zeit, also die default Einstellung, genutzt werden. Selbst
damit können die letzten Löschungen in den allermeisten Fällen
wieder recovert werden. Es gibt jedoch einige Ausnahmen bei denen
diese Variante nicht genau genug oder gar nicht funktioniert.
Dieses ist zB. der Fall, wenn Dateien überschrieben wurden, und
man den Stand vor dem Überschreiben recovern möchte. Auch wenn
nach einem Löschvorgang noch größer Schreibaktionen im
Filesystem gelaufen sind, ist diese Variante nicht die beste Wahl.
Ebenfalls nicht zuverlässig genug ist die Variante bei optionalen
Benutzung der Option "-Q"
, sowie wenn im Filessystem oder den Dateien Optionen oder
Attribute aktiv waren, die ein synchrones Schreiben der Daten
erzwingen. ZB die Dateiattribute "D" ;
"S"
oder "j".
(Manpage von
chattr)
Die zweite Variante ist in der Ermittlung des
genauen zeitlichen Begins des Löschvorganges etwas aufwendiger,
dafür ist sie zuverlässiger und bearbeitet die Ausnahmen aus der
oben vorgestellten Variante besser. Der "BEFORE"
Zeitpunkt sollte dazu je nach Aktivität den Zeitpunkt des Beginnes
des Löschvorganges bis auf wenige Sekunden genau treffen. Wird der
Zeitpunkt zu früh vor dem Löschzeitpunkt gesetzt, wird eventuell
nicht die letzte Inodekopie vor dem Löschen gefunden. Wird eine
Zeitpunkt gewählt zu dem der Löschvorgang bei einigen Dateien
schon gelaufen ist, schlagen sofort die Ausnahmen der ersten
Variante wieder auf einigen Dateien und Verzeichnissen durch.
Die "AFTER" Zeitmarke muss zeitlich immer vor die
"BEFORE" Zeit gesetzt werden und soll nur verhindern,
dass zu alte Daten zu recovert werden. Diese Zeitmarke ist
unkritischer in ihren Auswirkungen auf den Prozessablauf selbst.
Sie sollte jedoch zB im Histogramm ersichtliche frühere
Löschvorgänge klar und sauber von dem Recover ausschließen. Zu
beachten allerdings, diese Zeit ist per default auf die letzten 24
Stunden vor dem Befehlsaufruf von ext4magic eingestellt und muss zB
unbedingt gesetzt werden, wenn eine Löschung schon länger
zurückliegt oder die "BEFORE" Zeit mehr als 24 Stunden
zurück datiert wird. Sonst werden überhaupt keine Dateien zum
recovern gefunden, oder der Programmaufruf gibt schon beim Start
einen Fehler, wegen unlogischer Zeitoptionen.
Somit ist die "BEFORE" Zeitmarke die Zeitoption
mit der versucht wird, durch die Zeitschichten des Filesystems zu
steuern. Die "AFTER" Zeitmarke begrenzt die Zeit nach
unten, so dass nicht zu alte Dateien gefunden werden, bzw frühere
Versionen mit gleichem Dateinamen ignoriert werden.
ROBI@LINUX:/mnt/attr_test # ls -il total 3 29186 -rw-r--r-- 3 root root 79 Aug 7 03:23 file_1 29186 -rw-r--r-- 3 root root 79 Aug 7 03:23 file_2 29186 -rw-r--r-- 3 root root 79 Aug 7 03:23 file_3 ROBI@LINUX:/mnt/attr_test # lsattr file* ------d--j----- file_1 ------d--j----- file_2 ------d--j----- file_3 ROBI@LINUX:/mnt/attr_test # rm file* ROBI@LINUX:/mnt/attr_test #
ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso -I 29186 -J ..... Dump Inode 29186 from journal transaction 82178 Inode: 29186 Type: regular Mode: 0644 Flags: 0x40 Generation: 2677469721 Version: 0x00000000 User: 0 Group: 0 Size: 79 File ACL: 0 Directory ACL: 0 Links: 3 Blockcount: 2 Fragment: Address: 0 Number: 0 Size: 0 ctime: 1281144289 -- Sat Aug 7 03:24:49 2010 atime: 1281144185 -- Sat Aug 7 03:23:05 2010 mtime: 1281144185 -- Sat Aug 7 03:23:05 2010 Dump Inode 29186 from journal transaction 82183 Inode: 29186 Type: regular Mode: 0644 Flags: 0x4040 Generation: 2677469721 Version: 0x00000000 User: 0 Group: 0 Size: 79 File ACL: 0 Directory ACL: 0 Links: 2 Blockcount: 2 Fragment: Address: 0 Number: 0 Size: 0 ctime: 1281182810 -- Sat Aug 7 14:06:50 2010 atime: 1281144401 -- Sat Aug 7 03:26:41 2010 mtime: 1281144185 -- Sat Aug 7 03:23:05 2010 Dump Inode 29186 from journal transaction 82184 Inode: 29186 Type: regular Mode: 0644 Flags: 0x4040 Generation: 2677469721 Version: 0x00000000 User: 0 Group: 0 Size: 79 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 2 Fragment: Address: 0 Number: 0 Size: 0 ctime: 1281182810 -- Sat Aug 7 14:06:50 2010 atime: 1281144401 -- Sat Aug 7 03:26:41 2010 mtime: 1281144185 -- Sat Aug 7 03:23:05 2010 Dump Inode 29186 from journal transaction 82185 Inode: 29186 Type: regular Mode: 0644 Flags: 0x4040 Generation: 2677469721 Version: 0x00000000 User: 0 Group: 0 Size: 79 File ACL: 0 Directory ACL: 0 Links: 0 Blockcount: 2 Fragment: Address: 0 Number: 0 Size: 0 ctime: 1281182810 -- Sat Aug 7 14:06:50 2010 atime: 1281144401 -- Sat Aug 7 03:26:41 2010 mtime: 1281144185 -- Sat Aug 7 03:23:05 2010 Dump Inode 29186 from journal transaction 82186 Inode: 29186 Type: regular Mode: 0644 Flags: 0x4040 Generation: 2677469721 Version: 0x00000000 User: 0 Group: 0 Size: 0 File ACL: 0 Directory ACL: 0 Links: 0 Blockcount: 0 Fragment: Address: 0 Number: 0 Size: 0 ctime: 1281182810 -- Sat Aug 7 14:06:50 2010 atime: 1281144401 -- Sat Aug 7 03:26:41 2010 mtime: 1281182810 -- Sat Aug 7 14:06:50 2010 dtime: 1281182810 -- Sat Aug 7 14:06:50 2010
Zu erkennen hier innerhalb einer Sekunde wurden jetzt mehrere Inodekopien angelegt, in denen zu erkennen ist, wie die einzelnen Dateien entlinkt wurden. Und erst nachdem die Inode keine Links mehr hatte, wurde sie gelöscht.
ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso -f attr_test -r -b 1281182810 "RECOVERDIR" accept for recoverdir Filesystem in use: testfile.iso Using internal Journal at Inode 8 Activ Time after : Fri Aug 6 19:49:54 2010 Activ Time before : Sat Aug 7 14:06:50 2010 Inode found "attr_test" 29185 Inode 29185 is allocated -------- RECOVERDIR/attr_test/file_2 -------- RECOVERDIR/attr_test/file_1 -------- RECOVERDIR/attr_test/file_3 Hardlink Database all Hardlinks be resolved ROBI@LINUX:/tmp/test1 # ls -il RECOVERDIR/attr_test/* 783371 -rw-r--r-- 3 root root 79 Aug 7 03:23 RECOVERDIR/attr_test/file_1 783371 -rw-r--r-- 3 root root 79 Aug 7 03:23 RECOVERDIR/attr_test/file_2 783371 -rw-r--r-- 3 root root 79 Aug 7 03:23 RECOVERDIR/attr_test/file_3
Zu erkennen jetzt, die Dateien konnten jetzt komplett richtig recovert werden, alle Dateien wurden beim recovern auf die selbe Inode verlinkt.
ROBI@LINUX:/home/rob/test1 # ext4magic testfile.iso -f test2 -a 1272329366 -b 1272329563 | grep -A10 found Inode found "test2" 8193 Inode: 8193 Type: directory Mode: 0755 Flags: 0x80000 Generation: 1223186497 Version: 0x00000000:00000006 User: 0 Group: 0 Size: 4096 File ACL: 0 Directory ACL: 0 Links: 2 Blockcount: 8 Fragment: Address: 0 Number: 0 Size: 0 ctime: 1272329543:0773929352 -- Tue Apr 27 02:52:23 2010 atime: 1272329543:0769928392 -- Tue Apr 27 02:52:23 2010 mtime: 1272329543:0773929352 -- Tue Apr 27 02:52:23 2010 crtime: 1272329543:0769928392 -- Tue Apr 27 02:52:23 2010 ROBI@LINUX:/home/rob/test1 # ext4magic testfile.iso -f test2 -a 1272329366 -b 1272329564 | grep -A10 found Inode found "test2" 12 Inode: 12 Type: directory Mode: 0755 Flags: 0x80000 Generation: 1223186388 Version: 0x00000000:00000059 User: 0 Group: 0 Size: 4096 File ACL: 0 Directory ACL: 0 Links: 8 Blockcount: 8 Fragment: Address: 0 Number: 0 Size: 0 ctime: 1272329563:1925916860 -- Tue Apr 27 02:52:43 2010 atime: 1272329563:1964948684 -- Tue Apr 27 02:52:43 2010 mtime: 1272329478:1493926496 -- Tue Apr 27 02:51:18 2010 crtime: 1272329401:3300921352 -- Tue Apr 27 02:50:01 2010
# ext4magic testfile.iso -f test2 -a 1272329366 -b 1272329563 -r
# ext4magic testfile.iso -f test2 -a 1272329366 -b 1272329564 -r
Fehlersituation: Es wurden in einem Verzeichnis durch die Verwendung eines falschen Befehles in einem Script nicht Thumbnails von den Bildern erzeugt, sondern die originalen Bilder mit den eigenen Thumbnails überschrieben. Ergebnis die Originalbilder sind verschwunden, dafür verkleinerte Kopien mit den gleichen Namen im Verzeichnis.
ROBI@LINUX:/home/rob/test # ext4magic testfile.iso -f "user1" -T | grep -A15 transaction ..... Dump Inode 60929 from journal transaction 3341 Inode: 60929 Type: directory Mode: 0755 Flags: 0x0 Generation: 301560004 Version: 0x00000000 User: 0 Group: 0 Size: 1024 File ACL: 0 Directory ACL: 0 Links: 2 Blockcount: 2 Fragment: Address: 0 Number: 0 Size: 0 ctime: 1275076684 -- Fri May 28 21:58:04 2010 atime: 1275076686 -- Fri May 28 21:58:06 2010 mtime: 1275076684 -- Fri May 28 21:58:04 2010 60929 d 755 (2) 0 0 1024 28-May-2010 21:58 . 2 d 755 (2) 0 0 1024 28-May-2010 21:56 .. 60930 _ 755 (1) 0 0 1868983 28-May-2010 21:58 cimg1433.jpg 60931 _ 755 (1) 0 0 1865355 28-May-2010 21:58 cimg1434.jpg 60932 _ 755 (1) 0 0 2022342 28-May-2010 21:58 cimg1435.jpg 60933 _ 755 (1) 0 0 1871073 28-May-2010 21:58 cimg1436.jpg -- Dump Inode 60929 from journal transaction 3347 Inode: 60929 Type: directory Mode: 0755 Flags: 0x0 Generation: 301560004 Version: 0x00000000 User: 0 Group: 0 Size: 1024 File ACL: 0 Directory ACL: 0 Links: 2 Blockcount: 2 Fragment: Address: 0 Number: 0 Size: 0 ctime: 1275076887 -- Fri May 28 22:01:27 2010 atime: 1275076686 -- Fri May 28 21:58:06 2010 mtime: 1275076887 -- Fri May 28 22:01:27 2010 60929 d 755 (2) 0 0 1024 28-May-2010 22:01 . 2 d 755 (2) 0 0 1024 28-May-2010 21:56 .. 60957 _ 644 (1) 0 0 51823 28-May-2010 22:01 cimg1433.jpg 60930 _ 644 (1) 0 0 42837 28-May-2010 22:01 cimg1434.jpg 60931 _ 644 (1) 0 0 47361 28-May-2010 22:01 cimg1435.jpg 60932 _ 644 (1) 0 0 43670 28-May-2010 22:01 cimg1436.jpg -- ....
ROBI@LINUX:/home/rob/test # ext4magic testfile.iso -f "user1" -b 1275076685 -l Filesystem in use: testfile.iso Using internal Journal at Inode 8 Activ Time after : Thu May 27 23:02:29 2010 Activ Time before : Fri May 28 21:58:05 2010 Inode found "user1" 60929 Inode 60929 is allocated 92% user1/cimg1433.jpg 88% user1/cimg1434.jpg 94% user1/cimg1435.jpg 100% user1/cimg1436.jpg 100% user1/cimg1437.jpg 100% user1/cimg1438.jpg 100% user1/cimg1439.jpg 100% user1/cimg1441.jpg 100% user1/cimg1442.jpg 100% user1/cimg1443.jpg 100% user1/cimg1444.jpg 100% user1/cimg1445.jpg 100% user1/cimg1446.jpg 100% user1/cimg1456.jpg 100% user1/cimg1457.jpg ....
ROBI@LINUX:/home/rob/test # ext4magic testfile.iso -f "user1" -b 1275076685 -r "RECOVERDIR" accept for recoverdir Filesystem in use: testfile.iso Using internal Journal at Inode 8 Activ Time after : Thu May 27 23:08:23 2010 Activ Time before : Fri May 28 21:58:05 2010 Inode found "user1" 60929 Inode 60929 is allocated -------- RECOVERDIR/user1/cimg1436.jpg -------- RECOVERDIR/user1/cimg1437.jpg -------- RECOVERDIR/user1/cimg1438.jpg -------- RECOVERDIR/user1/cimg1439.jpg -------- RECOVERDIR/user1/cimg1441.jpg -------- RECOVERDIR/user1/cimg1442.jpg -------- RECOVERDIR/user1/cimg1443.jpg -------- RECOVERDIR/user1/cimg1444.jpg -------- RECOVERDIR/user1/cimg1445.jpg -------- RECOVERDIR/user1/cimg1446.jpg ......
ROBI@LINUX:/home/rob/test # ls -l RECOVERDIR/user1/cimg* -rwxr-xr-x 1 root root 1871073 May 28 21:58 RECOVERDIR/user1/cimg1436.jpg -rwxr-xr-x 1 root root 2039840 May 28 21:58 RECOVERDIR/user1/cimg1437.jpg -rwxr-xr-x 1 root root 2061072 May 28 21:58 RECOVERDIR/user1/cimg1438.jpg -rwxr-xr-x 1 root root 1844663 May 28 21:58 RECOVERDIR/user1/cimg1439.jpg -rw-r--r-- 1 root root 715779 May 28 21:58 RECOVERDIR/user1/cimg1441.jpg -rw-r--r-- 1 root root 2165891 May 28 21:58 RECOVERDIR/user1/cimg1442.jpg -rw-r--r-- 1 root root 747751 May 28 21:58 RECOVERDIR/user1/cimg1443.jpg -rw-r--r-- 1 root root 728500 May 28 21:58 RECOVERDIR/user1/cimg1444.jpg -rw-r--r-- 1 root root 810420 May 28 21:58 RECOVERDIR/user1/cimg1445.jpg -rw-r--r-- 1 root root 953308 May 28 21:58 RECOVERDIR/user1/cimg1446.jpg ......
ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso -H -a 1272299456 -b 1272375077 Filesystem in use: testfile.iso |-----------c_time Histogram----------------- after -------------------- Mon Apr 26 18:30:56 2010 1272307018 : 0 | | Mon Apr 26 20:36:58 2010 1272314580 : 0 | | Mon Apr 26 22:43:00 2010 1272322142 : 0 | | Tue Apr 27 00:49:02 2010 1272329704 : 11 |**************************************************| Tue Apr 27 02:55:04 2010 1272337266 : 0 | | Tue Apr 27 05:01:06 2010 1272344828 : 0 | | Tue Apr 27 07:07:08 2010 1272352390 : 0 | | Tue Apr 27 09:13:10 2010 1272359952 : 0 | | Tue Apr 27 11:19:12 2010 1272367514 : 0 | | Tue Apr 27 13:25:14 2010 1272375076 : 0 | | Tue Apr 27 15:31:16 2010 |-----------d_time Histogram----------------- after -------------------- Mon Apr 26 18:30:56 2010 1272307018 : 0 | | Mon Apr 26 20:36:58 2010 1272314580 : 0 | | Mon Apr 26 22:43:00 2010 1272322142 : 0 | | Tue Apr 27 00:49:02 2010 1272329704 : 103 |**************************************************| Tue Apr 27 02:55:04 2010 1272337266 : 0 | | Tue Apr 27 05:01:06 2010 1272344828 : 0 | | Tue Apr 27 07:07:08 2010 1272352390 : 0 | | Tue Apr 27 09:13:10 2010 1272359952 : 0 | | Tue Apr 27 11:19:12 2010 1272367514 : 0 | | Tue Apr 27 13:25:14 2010 1272375076 : 0 | | Tue Apr 27 15:31:16 2010 |-----------cr_time Histogram----------------- after -------------------- Mon Apr 26 18:30:56 2010 1272307018 : 0 | | Mon Apr 26 20:36:58 2010 1272314580 : 0 | | Mon Apr 26 22:43:00 2010 1272322142 : 0 | | Tue Apr 27 00:49:02 2010 1272329704 : 10 |**************************************************| Tue Apr 27 02:55:04 2010 1272337266 : 0 | | Tue Apr 27 05:01:06 2010 1272344828 : 0 | | Tue Apr 27 07:07:08 2010 1272352390 : 0 | | Tue Apr 27 09:13:10 2010 1272359952 : 0 | | Tue Apr 27 11:19:12 2010 1272367514 : 0 | | Tue Apr 27 13:25:14 2010 1272375076 : 0 | | Tue Apr 27 15:31:16 2010
Durch das einschachteln auf den aktiven Zeitraum bis auf 30 Sekunden Auflösung, ergibt sich beim selben Filesystem
ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso -H -a 1272329366 -b 1272329672 Filesystem in use: testfile.iso |-----------c_time Histogram----------------- after -------------------- Tue Apr 27 02:49:26 2010 1272329396 : 0 | | Tue Apr 27 02:49:56 2010 1272329426 : 5 |************************* | Tue Apr 27 02:50:26 2010 1272329456 : 0 | | Tue Apr 27 02:50:56 2010 1272329486 : 5 |************************* | Tue Apr 27 02:51:26 2010 1272329516 : 0 | | Tue Apr 27 02:51:56 2010 1272329546 : 0 | | Tue Apr 27 02:52:26 2010 1272329576 : 0 | | Tue Apr 27 02:52:56 2010 1272329606 : 1 |***** | Tue Apr 27 02:53:26 2010 1272329636 : 0 | | Tue Apr 27 02:53:56 2010 1272329666 : 0 | | Tue Apr 27 02:54:26 2010 |-----------d_time Histogram----------------- after -------------------- Tue Apr 27 02:49:26 2010 1272329396 : 0 | | Tue Apr 27 02:49:56 2010 1272329426 : 0 | | Tue Apr 27 02:50:26 2010 1272329456 : 0 | | Tue Apr 27 02:50:56 2010 1272329486 : 0 | | Tue Apr 27 02:51:26 2010 1272329516 : 0 | | Tue Apr 27 02:51:56 2010 1272329546 : 7 |**** | Tue Apr 27 02:52:26 2010 1272329576 : 3 |** | Tue Apr 27 02:52:56 2010 1272329606 : 93 |**************************************************| Tue Apr 27 02:53:26 2010 1272329636 : 0 | | Tue Apr 27 02:53:56 2010 1272329666 : 0 | | Tue Apr 27 02:54:26 2010 |-----------cr_time Histogram----------------- after -------------------- Tue Apr 27 02:49:26 2010 1272329396 : 0 | | Tue Apr 27 02:49:56 2010 1272329426 : 25 |***************** | Tue Apr 27 02:50:26 2010 1272329456 : 0 | | Tue Apr 27 02:50:56 2010 1272329486 : 75 |**************************************************| Tue Apr 27 02:51:26 2010 1272329516 : 7 |***** | Tue Apr 27 02:51:56 2010 1272329546 : 3 |** | Tue Apr 27 02:52:26 2010 1272329576 : 3 |** | Tue Apr 27 02:52:56 2010 1272329606 : 0 | | Tue Apr 27 02:53:26 2010 1272329636 : 0 | | Tue Apr 27 02:53:56 2010 1272329666 : 0 | | Tue Apr 27 02:54:26 2010
Hierbei ist zu beachten, das wir in dieser Auflösung bedeutend mehr Inode bei der crtime . Das resultiert daraus, das hier die Dateien jeweils nur ein kurzes Leben hatten und fast alle schnell wieder gelöscht wurden. In der groben Auflösung von oben sind sie an der nachten Zeitmarke schon gelöscht, und desshalb wird die crtime dieser Dateien nicht angezeigt. In der unteren feinen Auflösung sind die Dateien an den Zeitmarken noch nicht gelöscht und werden so gezählt.
|
Ext4magic: Inode - Directory - Journal - Installation - Zeit-Optionen - Tricks&Tipps - Manpage - Expert-Mode |