|
Ext4magic: Inode - Directory - Journal - Installation - Zeit-Optionen - Tricks&Tipps - Manpage - Expert-Mode |
Inhaltsverzeichnis |
|
Achtung: |
|
Die direkte Nutzung des Journals eines aktuell noch read-write eingehängten Filesystems erzeugt Fehler und falsche Ergebnisse |
Ein Filesystem sollte vor der Benutzung
mit ext4magic zuerst umount
oder zu mindestens read-only mount
werden. In einigen Fällen wird dieses nicht möglich sein, und
auch der Verlust einer einzigen Datei wird nicht immer diesen
Aufwand wirklich rechtfertigen. ext4magic hat für einmalige
kleinere Aktionen eine Umgehung dieses Problems, welche allerdings
derzeit noch als experimentell eingestuft wird.
Beim Lesen des Journals wird der Cache des Filesystems genutzt, das bedeutet Linux hält den Inhalt oder wesentliche Teile von der Journalfile im Hauptspeicher nachdem sie das erste Mal gelesen wurde, und greift dann beim Lesen nur auf den Hauptspeicher und nicht mehr auf die Platte zurück. Das ist auch für extmagic notwendig da sehr viele Zugriffe auf die Blöcke oft mehrfach erfolgen und dieses bedeutend schneller ist, als die Blöcke immer wieder neu zu lesen.
Linux selbst schreibt ungepuffert in das Journal direkt auf die
Platte. Warum und wieso konnte noch nicht untersucht werden, aus
irgend einem Grund werden dadurch die Daten im Filesystem Cache
innerhalb der Journalfile trotzdem verändert. Das Ergebnis ist:
ext4magic ließt ab der Position an der das Journal gerade
seine Logs weiter schreibt, falsche Blöcke. Und das genau ab dem
Moment wenn das Journal das erste Mal als File geöffnet wird. Das
bedeutet, der aller erste Zugriff von ext4magic auf das Journal und
der dazugehörige List- oder Recoverprozess der damit an gestartet
wird, läuft noch normal, solange er nicht zu zeitaufwendig ist.
Wird jetzt im Filesystem gearbeitet und dadurch das Journal
verändert, dann wird ein späterer 2. Aufruf von ext4magic
anschließend ein paar komplett falsche Blöcke lesen, und dieses
wird mit jedem Versuch schlimmer. Selbst wenn jetzt eine Kopie des
Journals mit den offiziellen Tools angefertigt wird, wird diese
Kopie ebenfalls diese Fehler beinhalten. Dieser Fehler verschwindet
erst wieder, wenn das Filesystem komplett ausgehängt wird und
wieder neu gemountet wird, (ein remount reicht nicht) erst dann
sind die Blöcke im Journal wieder als die Richtigen lesbar.
Wahrscheinlich wird nach einer gewissen Zeit, abhängig von der
Speicherausstattung und der Speicherbenutzung des Rechners, das
Journal irgend wann aus dem Cache des Filesystems verdrängen, das
kann aber so nicht genau bestimmt oder vorhersagt werden.
Mit ext4magic wirklich mit dem ersten
Versuch das gewünschte Ergebnis zu erreichen, ohne vorher die
Journal- und Inode Daten näher anzuschauen, ist nicht sehr
wahrscheinlich. Wenn das Filesystem nicht read-only oder ganz
ausgehängt wurde, das Filesystem jetzt dazu zu bewegen nicht ins
Journal zu schreiben, ist utopisch. (siehe
Journal)
Es muss mit dem ersten öffnen des Journals
eine Kopie dieses Journals angelegt werden, und später nur diese
Kopie anstatt des original Journals benutzt werden.
Das Journal
ist eine Sonderfile im Dateisystem welche auch keinen
Verzeichniseintrag besitzt und welche nur über die Inodenummer
selbst angesprochen werden kann. Das interne Journal eines ext3/4
Filesystems nutzt per default immer die Inodenummer 8 für das
Journal. Mit dem Befehl debugfs
kann eine Kopie des Journals erstellt werde.
Aber wichtig: auch
nur die erste Kopie ist in Ordnung, werden später weitere Kopien
angefertigt solange das Journal noch vom ersten Auslesen im Cache
steht, haben diese Kopien die selben Fehler. Auch das Auslesen des
Journals über debugfs bewirkt also ein cachen des Journals im
Speicher. Also nicht erst mit ext4magic probieren, sondern zu aller
erst mit debugfs eine Kopie vom Journal erstellen, und zwar im
Ersten Versuch.
# debugfs -R "dump <8> /PATH/journal.copy" /dev/device
"/PATH/journal.copy" steht hier symbolisch für den Dateinamen der Journalkopie. Diese sollte dringend auf einem anderem Filesystem angelegt werden. "/dev/device" ist das Blockdevice oder die Partition auf der das zu untersuchende Filesystem sich befindet.
Mit dieser Momentaufnahme vom Journal kann ext4magic genauso arbeiten wie mit dem internen Journal, es muss nur bei Start als Option angegeben werden, dann wird dieses benutzt und nicht das interne des Filesystems
# ext4magic /dev/device -j /PATH/journal.copy .........
Selbstverständlich sollte man wenn es möglich ist, jetzt im Filesystem nicht mehr schreiben als es unbedingt notwenig ist. Jedes Schreiben kann Filesystemblöcke überschreiben die zu den den Dateien gehört haben, die wir jetzt gerne wieder gewinnen möchten. Nur ein überschriebener Datenblock bedeutet je nach Recoveroption die Datei wird überhaupt nicht mehr wiederhergestellt, oder ist nach dem Wiederherstellen stellenweise oder ganz defekt.
Es handelt sich hier um eine experimentelle Funktion mit der während der Entwicklung versucht wurde das Recovern von wiederverwendeten Inode und doppelten Dateinamen zu verhindern. Auf der einen Seite funktioniert diese Option hervorragend und ergibt sehr gute Ergebnisse, das ist auch der Grund warum sie nicht entfernt wurde. Auf der anderen Seite sind die Anforderungen auf den Inhalt des Journals sehr hoch, so das der Journalinhalt die Voraussetzungen nur für bestimmte Verzeichnisse oder Filesystemabschnitte erfüllen kann. Das Recover mit dieser Option aus Filesystemabschnitten ohne die entsprechenden Journaldaten bringt sehr schlechte Ergebnisse. Mit der Verwendung dieser Option auf ein ganzes Filesystem wird man deshalb das genaue Gegenteil dessen erreichen, was man angestrebt hat. Desshalb sollte man diese Option, wenn überhaupt, dann nur beim einem Recoverversuch auf einen eng begrenztem Filesystemabschnitt versuchen. Erfolg kann man sich aus Verzeichnissen erhoffen, in denen sich sehr oft Dateien ändern. zB. in Arbeitsverzeichnissen in denen oft Dateien mit einem Editor bearbeitet und unter dem selben Namen wieder abgespeichert werden und dabei immer automatisch eine Backupdatei angelegt wird.
Da diese Funktion weniger häufig genutzt werden kann und
durch für den normalen Anwender wenig durchschaubare
Voraussetzungen für erfolgversprechende Ergebnisse benötigt, wird
in der nächsten Version diese Option in den Pool der
Expert-Funktionen verschoben.
Es wird beim Recovern intern entsprechend des ausgewählten Zeitfensters nach ungelöschten Inodekopien im Journal gesucht. Bei Verzeichnissen wird dann ebenfalls noch nach Kopien der Verzeichnisdatenblöcke gesucht welche zeitlich zur gefunden Inodekopie passen. Wird eine zeitlich passende Kopie dieser Verzeichnisdaten nicht gefunden, dann wird die nächst jüngere Kopie aus dem Journal verwendet und ist auch solch eine nicht zu finden, dann letztlich der Originalblock aus dem Filesystem. Der zeitliche Unterschied in den dabei letztendlich verwendeten Verzeichnisdatenblöcken fällt dabei kaum ins Gewicht, da ext4magic mit den default Optionen alle Verzeichniseinträge auswertet. Ob in dem Datenblock die Inodenummer-Dateiname-Kombination als gelöscht markiert ist oder nicht gelöscht markiert ist, wird nicht unterschieden. Dieses ist jedoch die Ursache für das Entstehen von Recoverfehlern durch wiederverwendete Dateinamen und wiederverwendete Inodenummern.
Durch die Verwendung der "-Q" Option wird ext4magic dazu aufgefordert in den Verzeichnisdatenblöcken die gelöschten Einträge zu überspringen und nicht auszuwerten. Damit wird verhindert das es doppelte Dateinamen geben kann und längst gelöschte Inodenummer-Dateinamen Verbindungen recovert werden, wenn die Inode in der Zwischenzeit wieder verwendet wurde. Das kann aber nur funktionieren wenn der verwendete Verzeichnisdatenblock auch zeitlich zur Inodekopie passt und nicht aus der Zeit stammt, in der die Dateien, welche wieder hergestellt werden sollen, schon gelöscht sind.
Inodekopien werden viel häufiger im Journal
angelegt als man vermuten würde. (siehe
auch)
Kopien von den Verzeichnisdatenblöcken werden nur
angelegt wenn sie sich geändert haben, und besitzt ein Verzeichnis
mehrere Datenblöcke wird auch immer nur eine Kopie des
Datenblockes abgelegt der sich geändert hat. Dieses führt jetzt
dazu, das die Option "-Q" nur in wenigen Einzelfällen
wirklich eine Aussicht auf Erfolg hat und meist nur schlechtere
Ergebnisse liefern kann.
Images von Filesystempartitionen lassen sich direkt von ext4magic nutzen. Anders bei Images von ganzen Platten. Hier liegen die Filesystem auf den Partitionen dieses Images und können nur über Loopdevices genutzt werden. Der Befehl zum verbinden einer solchen Partition mit einem Loopdevice ist losetup. Da die Partitionen zwangsläufig nicht am Anfang der Imagedatei steht, muss hierbei mit einem Offsetwert gearbeitet werden der in Byte genau den Beginn der Partition innerhalb des Images angibt. Der Offsetwert kann aus der Partitionstabelle des Images errechnet werden. Für die einfachere Handhabung hier ein kleines Hilfscript, das die Daten aus der Partitionstabelle ließt und die Berechnung vornehmen kann.
#!/bin/bash # help-loop-image # Script soll helfen den richtigen Offset für Partitionen # eines kompletten Platten Images herauszufinden. # Autor: robi6@users.sf.net (Version 1.0 vom 25.04.2011) PATH="/sbin:$PATH" if [ $# -lt 1 ] then echo "usage: ${0##*/} <image>" exit 1 fi IMAGE=$1 if [ ! -f "$IMAGE" ] then echo "ERROR: $IMAGE ist kein File" exit 2 fi LANG=C fdisk -lu "$IMAGE" 2>&1 | tr -d '*' | egrep "${IMAGE}[p]*[0-9]" | while read part start end blocks id rest do echo echo "# $read $part $start $end $blocks $id $rest" case $id in f) echo "Ignoriere extended partition" continue ;; 82) echo "Ignoriere Swap" continue ;; *) ;; esac let offset=$start*512 echo "losetup -f \"$IMAGE\" -o $offset" done exit 0
dieses Script als "help-loop-image" abspeichern und Ausführungsrechte darauf vergeben. Aufgerufen wird das Script dann einfach mit dem Image
./help-loop-image IMAGEDATEI
Dieses Script wird die möglichen Datenpartitionen 1-9 des Images
anzeigen und jeweils den genauen losetup Befehl mit dem
errechneten Offsetwert darunter ausgeben.
Den entsprechenden
Befehl für das zu untersuchende Filesystem dann heraussuchen und
als root absetzen. Anschließend und mit dem Befehl
losetup -a
nachschauen auf welches Loopdevice diese Partition jetzt gebunden wurden. Mit ext4magic kann dann dieses Loopdevice jetzt wie eine normale Filesystempartition angesprochen werden.
ext4magic /dev/loop0 -S
Nach Abschluss der Arbeit mit ext4magic sollte dieses Loopdevice wieder freigegeben werden
losetup -d /dev/loop0
Mit ext4magic können auch von verschlüsselten ext3/ext4 Filesystemen versehentlich gelöschte Dateien wieder recovert werden. Dazu wird das virtuelle Blockgerät benötigt auf dem das Filesystem entschlüsselt abgebildet ist, ohne das das Filesystem zu diesem Zeitpunkt gemountet ist. In meisten Fällen ist dazu etwas Handarbeit notwendig, da die Konfiguration und die im Normalfall ablaufenden Automatismen verhindern sollten, dass das Filesystem im ungemounteten Zustand entschlüsselt erreichbar ist. Wie dabei vorzugehen ist, ist abhängig von der verwendeten Verschlüsselungstechnik und in den entsprechenden Dokumentationen nachzulesen. Sollte dieses nicht möglich sein, dann ist das verschlüsselte Filesystem zu mindestens readonly zu mounten. Dazu muss das Filesystem komplett umountet werden, ein remount nach readonly reicht nicht aus.
Als Beispiel hier die Vorgehensweise bei einem mit LUKS verschlüsseltem Container. Die Containerfile ist in diesem Beispiel die Datei /home/test/crypt.iso die zur Zeit nicht konfiguriert und nicht eingebunden ist.
ROBI@LINUX:~ # file crypt.iso crypt.iso: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1] UUID: 2ca7be95-439d-499e-849e-cbba5de ROBI@LINUX:~ # losetup -a ROBI@LINUX:~ # losetup /dev/loop0 crypt.iso ROBI@LINUX:~ # losetup -a /dev/loop0: [0806]:1011860 (/home/test/crypt.iso) ROBI@LINUX:~ # file -s /dev/loop0 /dev/loop0: LUKS encrypted file, ver 1 [aes, cbc-essiv:sha256, sha1] UUID: 2ca7be95-439d-499e-849e-cbba5de
In diesem ersten Abschnitt wird der Container mit einem freiem Loopdevice verbunden, hier mit /dev/loop0
Danach wird das LUKS-Volumen dann geöffnet und damit die
virtuelle Filesystemschicht in einem Device unterhalb von
/dev/mapper/ eingerichtet.
In diesem Beispiel /dev/mapper/cr_crypt.iso ROBI@LINUX:~ # cryptsetup luksOpen /dev/loop0 cr_crypt.iso Enter LUKS passphrase for /dev/loop0: key slot 0 unlocked. Command successful. ROBI@LINUX:~ # file -s /dev/mapper/cr_crypt.iso /dev/mapper/cr_crypt.iso: Linux rev 1.0 ext4 filesystem data (extents) (huge files)
Der Befehl file -s .... zeigt jetzt, dieses ist das ext4 Filesystem. Und auf dieses Gerätedevice kann jetzt mit ext4magic zugegriffen werden. Hier im Beispiel werden gelöschte Dateien aus dem Verzeichnis "picture/" recovert.
ROBI@LINUX:~ # ext4magic /dev/mapper/cr_crypt.iso -r -f picture "RECOVERDIR" accept for recoverdir Filesystem in use: /dev/mapper/cr_crypt.iso Using internal Journal at Inode 8 Inode found "picture" 1817 Inode 1817 is allocated -------- RECOVERDIR/picture/cimg1442.jpg -------- RECOVERDIR/picture/cimg1434.jpg -------- RECOVERDIR/picture/test0004.tif -------- RECOVERDIR/picture/cimg1435.jpg -------- RECOVERDIR/picture/cimg1459.jpg -------- RECOVERDIR/picture/cimg1445.jpg -------- ......... ......
Nach beenden der Arbeit mit ext4magic nicht vergessen wieder aufzuräumen. In diesem Fall muss das LUKS-Volumen wieder geschlossen werden und die Verbindung mit dem Loopdevice wieder aufgelöst werden.
ROBI@LINUX:~ # cryptsetup luksClose /dev/mapper/cr_crypt.iso
ROBI@LINUX:~ # losetup -d /dev/loop0
Das folgende ist für Fortgeschrittene und beinhaltet ein Beispiel wie man mit Hilfe der Optionen von ext4magic auch Probleme lösen kann, die auf dem ersten Blick so leicht nicht lösbar erscheinen.
Die Histogrammfunktion zeigt folgende Ausgabe von der delete-Time:
ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso.3 -a 1286031225 -b 1286031288 -H Filesystem in use: testfile.iso.3 ...... |-----------d_time Histogram----------------- after -------------------- Sat Oct 2 16:53:45 2010 1286031231 : 3 |** | Sat Oct 2 16:53:51 2010 1286031237 : 0 | | Sat Oct 2 16:53:57 2010 1286031243 : 0 | | Sat Oct 2 16:54:03 2010 1286031249 : 49 |********************* | Sat Oct 2 16:54:09 2010 1286031255 : 0 | | Sat Oct 2 16:54:15 2010 1286031261 : 6 |*** | Sat Oct 2 16:54:21 2010 1286031267 : 117 |**************************************************| Sat Oct 2 16:54:27 2010 1286031273 : 53 |*********************** | Sat Oct 2 16:54:33 2010 1286031279 : 0 | | Sat Oct 2 16:54:39 2010 1286031285 : 0 | | Sat Oct 2 16:54:45 2010 ext4magic : EXIT_SUCCESS
Es sind hier 4 Löschvorgänge zu erkennen. Von Interesse ist die Löschung der 6 Dateien in der Zeitspanne von 16:54:15 bis 16:54:21. Mit diesem Löschvorgang wurden fälschlicherweise die Dateien gelöscht, die wir jetzt wieder recovern möchten.
Die Zeitoptionen können hier in ext4magic nicht direkt angewendet werden, um gezielt nur eine bestimmten Löschvorgang aus dieser Serie rückgängig zu machen. (Vergleiche auch). Es kann damit nur ein Zeitfenster bestimmt werden, von dem versucht werden kann, den dortigen aktuellen Stand zu recovern. Damit lässt sich nur der erste Löschvorgang (49 Dateien) ausschließen, doch die beiden Löschvorgänge die danach erfolgt sind ( 117 + 53) , lassen sich so mit den Zeitoptionen nicht ausschließen, da die Dateien zu diesem Zeitpunkt ebenfalls noch existiert haben und jetzt gelöscht sind. Nur mit den Zeitoptionen direkt könnten hier also nur die letzten Löschvorgänge alle zusammen komplett recovern werden, die dann auch die gesuchten Dateien enthalten würden.
Das Problem kann wie folgt umgangen werden. Es werden dabei
die LIST-Optionen genutzt, um Listen von recoverbaren Dateien zu
erstellen.
Die erste Liste soll nur den ersten Löschvorgang ausschließen und enthält somit die Dateien des 2 bis 4 Löschvorganges. also auch die gesuchten Dateien. Es wird dabei die Option "-l" in Verbindung mit der Option "-x" verwendet. Damit wird eine Liste erstellt, die ext4magic mit der Option "-i input_list" direkt verarbeiten kann. (siehe auch)
Eine zweite List wird genauso erstellt, diese enthält jetzt alle Dateien die nach dem entsprechenden Zeitpunkt gelöscht worden sind, also die Dateien die recovert werden sollen, sind dort nicht mehr enthalten.
Von diesen beiden Listen wird eine Differenzliste erstellt, und wenn alles richtig gelaufen ist, enthält sie genau die Dateinamen der Dateien die recovert werden sollen.
ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso.3 -a 1286031255 -b 1286031279 -lx > log_vor ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso.3 -a 1286031261 -b 1286031279 -lx > log_nach ROBI@LINUX:/tmp/test1 # diff log_vor log_nach 4c4 < Activ Time after : Sat Oct 2 16:54:15 2010 --- > Activ Time after : Sat Oct 2 16:54:21 2010 28,32d27 < 100% "tar/ext4magic-0.1.4.tar" < 100% "tar/backup.tgz" < 100% "tar/ext4magic-0.1.3.tar" < 100% "tar/ext4magic-0.1.2.tar" < 100% "tar/backup1.tgz" ROBI@LINUX:/tmp/test1 # diff log_vor log_nach > log_diff
Das sich in dieser Datei jetzt auch noch weitere Zeilen befinden, und das am Zeilenanfang noch ein Sonderzeichen und ein Prozentwert steht, ist für die Option "-i" nicht von Interesse, sie wertet pro Zeile nur aus, was sauber zwischen den doppelten Hochkommas eingeschlossen ist. Es wird jetzt nur noch ein Zeitfenster benötigt, in dem diese Dateien existiert haben und schon lassen sich die Dateien gezielt mit Hilfe der Liste recovern.
ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso.3 -a 1286031255 -b 1286031279 -r -i log_diff "log_diff" accept for inputfile "RECOVERDIR" accept for recoverdir Filesystem in use: testfile.iso.3 Using internal Journal at Inode 8 Activ Time after : Sat Oct 2 16:54:15 2010 Activ Time before : Sat Oct 2 16:54:39 2010 -------- RECOVERDIR/tar/ext4magic-0.1.4.tar -------- RECOVERDIR/tar/backup.tgz -------- RECOVERDIR/tar/ext4magic-0.1.3.tar -------- RECOVERDIR/tar/ext4magic-0.1.2.tar -------- RECOVERDIR/tar/backup1.tgz ext4magic : EXIT_SUCCESS
Aufmerksamen Lesern wird jetzt auffallen, es sind nur 5 Dateien, es sollten aber 6 sein. Des Rätsels Lösung, die 6. Inode war das Verzeichnis (tar/), welches dort mit gelöscht wurde und welches dann auch automatisch auch wieder mit hergestellt worden ist.
Die Ergebnisse des Magic-Scanners werden nicht in jedem Fall immer brauchbare Dateien ergeben. Bei einigen Dateitypen ist es ext4magic nicht immer möglich die Dateien auf richtige Länge zu zuschneiden. Es ist möglich einige Dateien sind um EINE oder wenige NULLen zu lang oder zu kurz. Anfällig dafür sind derzeit zB gzip Dateien und Windows Office Dokumente. Eine zu lange Datei wird meist beim öffnen eine Warnung erzeugen, sonst aber normal funktionieren. Anders jedoch zu kurze Dateien. Sie lassen sich oft nicht öffnen, ärgerlich bei komprimierten Formaten, wenn mehr als eine Datei enthalten ist..
Einige Dateitypen lassen sich sehr gut und
schnell über Plugins der grafischen Dateimanager überprüfen,
soweit man ein Desktop-System vor sich hat. Dazu zählen zB viele
Dokumentenformate, PDF, HTML , BILDER, und viele der gebräuchlichen
Mulitmediatypen.
Die gebräuchlichsten Bilderformate lassen sich
schnell und einfach mit "xv"
überprüfen.
Spezielle Bildformate lassen sich oft noch über
"display"
überprüfen, manchmal geht jedoch ohne gimp
nichts
Bei Textdateien ist es oftmals recht langwierig, sie zu
sortieren und zu sichten. more
oder less leisten
aber gute Dienste.
Nachfolgend eine kleine Sammlung von Befehlen mit denen
bestimmte Dateitypen mit Konsolbefehlen überprüft werden können.
In kleinen FOR-Schleifen verbaut ist somit schnell mal ein riesiges
Verzeichnis auf funktionierende Dateien überprüft. Mit ein wenig
Hintergrundwissen, zB das Open Office Dokumente fast alles durch
die Bank mit zip komprimiert sind, und man kommt hier schnell zum
Ziel. Den Inhalt muss man sich dann aber doch noch genauer
anschauen, um die Dateien zu sortieren die wichtigen Dateien
aufzufinden und ihnen wieder richtige Namen zu geben.
Befehle für das überprüfen von einigen ausgewählten Dateitypen
|
Dateitype |
Befehl |
|---|---|
|
gzip |
gzip -t DATEI.gz |
|
bzip2 |
bzip2 -t DATEI.bzip2 |
|
zip |
zip -T DATEI.zip |
|
xz |
xz -t DATEI.xz |
|
7z |
7z t DATEI,7z |
|
RAR |
rar t DATEI.rar |
|
tar |
tar -tf DATEI.tar >/dev/null |
|
cpio |
cpio -it < DATEI.cpio >/dev/null |
|
arj |
unarj t DATEI.arj |
|
Open Office Dokumente |
zip -T DATEI.o[dt]? |
|
jpeg |
djpeg -gr -scale 1/8 -bmp DATEI.jpeg > /dev/null |
Besonders ermüdend ist das überprüfen
von Audio- und Videofiles. Hierbei können kleine Scripte die erst
einmal prüfen ob die Datei überhaupt funktioniert bei der
Vorauswahl durchaus helfen. Als Tools die solche Dateien testen
können kommen zB MPlayer,
MEncoder oder für Audiodateien auch sox
in Frage. Mit folgenden Script kann man bei Auswertung der Ausgabe
zB schon mal erkennen ob die Dateien im Verzeichnis überhaupt
abspielbare Videodateien sind.
for i in * do echo "$i" mplayer -benchmark -nosound -vo null "$i" 2>/dev/null | grep BENCHMARK done
Bei Audiodateien könnte zB so was hier weiterhelfen
for i in * do echo -e "\n$i" sox "$i" -n stat done
Mit ein wenige Nachlesen in den entsprechenden Manpages sollten sich auf diese Weise durchaus schnell kleine Hilfsscripte schreiben lassen, mit denen man in kurzer Zeit automatisch größere Mengen recoverter Multimedia Dateien auf "Funktioniert" oder "ist Schrott", testen kann.
(Abschnitt ist noch in Bearbeitung, demnächst gehts weiter)
|
Ext4magic: Inode - Directory - Journal - Installation - Zeit-Optionen - Tricks&Tipps - Manpage - Expert-Mode |