Dateien auf korrekte Daten überprüfen

[himitsu]

Moin,

ich wollt mal gern fragen, ob hier jemand gute Möglichkeiten kennt (entwerder schon vorhandene Codes/Programme, oder Ideen wie man es machen könnte), womit/wie man verschiedenste Dateitypen auf intakte Dateiinhalte prüfen kann.

Delphilösungen (Win32), oder welche die man in ein Delphiprogramm einbinden kann würden mir am besten gefallen.


Grund ... hab hier mehrere Dateien (nach Datenrettung auf verschiedene Varianten/Optionen), welche unterschiedliche Bytes (Defekte) enthalten, obwohl die eigentlich gleich sein sollten.

Bei den meißten gepackten Archiven ist das ja oftmals recht einfach, aber anderesseits sagen viele Programme nichts, wenn die Dateien "defekt" sind und versuchen es so gut wie möglich anzuzeigen/zu verarbeiten.

Außerdem könnnten ja auch nur Daten hinten angehängt sein, so das die Datei O, wirkt, aber dennoch "defekt" ist.


Bilder werden sind z.B. untern total schwarz (Dateiende abgeschnitten), oder haben fehlerhafte Zeilen (defekte Sektoren) aber bemerken tut man es nur, wenn man überall reinguckt, was ja nicht immer wenig aufwand ist.

Oder mp3's, mpeg's ... hab hier einige, die unterscheiden sich in bis zu 'nem MB, obwohl sie rein optisch/akustisch gleich aussehn/klingen (das Viedeo hat aber auch schon durch die kompression einige Bildfehler ... es fallen also Neue nicht so schnell auf).

Es hier kommen auch schon mal total falsche Inhalte vor ... z.B. ein .jpeg und drin is 'ne EXE (da hatte aber der Vierenscanner schon gemekert) ... aber z.B. .pas mit irgendwas anderem drin is ja och möglich ... u.s.w.


Gesucht sind also Möglichkeiten die Ist-Zustände mit den Sollzuständen zu vergleichen.



's würde mir erstmal die Entscheidung, was ich hier löschen darf sehr erleichtern (auch wenn man im Moment keinen Unterschied sieht, will ich dennoch nur die intackteren Dateien behalten) und dann wäre es auch mal was ganz praktisches für ein Datenrettungs/-prüfprogramm :)



ein hoffnungsvoll wartender himi ^^

[mkinzler]

Am besten du erstellst für alle Dateien Prüfsummen speicherst diese und vergleichst sie regelmäßig mit dem aktuellen Stand.

[Go2EITS]

Moin, himitsu!
Hagen Filevergleich
Ich glaube, der Code von Hagen hilft Dir weiter.
GO2EITS :hi:

[himitsu]

Das Problem ist ja nicht die Dateien zu vergleichen ... ich weiß ja, daß sie unterschiedlich sind, also werd ich sie wohl bestimmt schon verglichen haben :zwinker:

Ich möchte wissen ob ihr Inhalt OK ist ... denn wenn die Dateien unterschiedlich sind, dann ist ja mindestens eine davon defekt, aber welche.

Es könnten ja auch beide futsch sein und wenn man dann Glück hat und weiß was fehlerhaft ist, dann könnte man ja vielleicht sogar aus beiden teilweise defekten Dateien eine Ganze machen :)

[add]
Bilddateien z.B.:
man könnte die ja in eine entsprechende Komponente laden und wenn sie defekt sind, dann gibt's halt 'nen Fehler ... da wüßte man zwar schonmal, daß dieses Bild entweder keines ist, oder es ist halt zu (weil ja auch teilweise defekte Bilder erfolgreich geladen werden ... nur halt mit "Pixelfehler") defekt.

[bigg]

Hi Himitsu,

vielleicht solltest du für dein Problem ein Dateisystem entwickeln, das deine Anforderungen erfüllt.
Schreib- und Lesevorgänge müssen auf Konsistenz überpüft werden, da hilft es aus meiner Sicht auch nicht an "defekten Daten" herumzudoktern.

http://de.wikipedia.org/wiki/Dateisystem
http://de.wikipedia.org/wiki/Journaling-Dateisystem

[himitsu]

das wäre dann wohl etwas weit ausgeholt, nur weil FAT und NTFS aus verschiedenen Gründen mal 'nen Fehler hat, gleich ein neues FS (mit nochmehr Overhead) zu entwickeln ^^
(die Dateien sind ja jetzt auf 'ner intakten Partition)

Ich möchte ja nur vorhandene Daten dahingehend prüfen können, ob die OK sind ... also z.B. ob in einer .jpeg-Datei wirklich ein JPeg drin ist und ob dieses auch intakt ist.
Und wenn nicht wie groß, oder was der Fehler ist.

[r2c2]

Schon mal vorneweg: Ich hab eigentlich keine Ahnung... :wink:

Möglichkeit für ASCII-Dateien: Es dürfen nur bestimmte Zeichen vorkommen(welche, sollten klar sein)
Möglichkeit für JPEG-Dateien: Header suchen(wie der aussieht steht bestimmt irgendwo(RFC, Wiki, google, ...)), vergleichen; Inhalt(größe) mit Header vergleichen

Auf jeden Fall wirst du für jedes Format ne neue Routine schreiben müssen und die wird in den wenigsten Fällen 100%ig sagen können, ob die Datei nun defekt ist, oder nicht. Propietäre Formate und Binaries machen natürlich noch mehr Probleme...

mfg

Christian

[Luckie]

Was du vorhast geht nicht, nicht ohne dass in jeder Datei eine Prüfsumme steht. Das ist genauso, als wenn du einen Schreibfehler in einem Text finden wolltest, dessen Sprache du aber nicht kennst und verstehst.

[himitsu]

OK, in 'nem BitMap könnte man defekte Pixel nicht finden, aber in den ganzen komprimierten Sachen sollte es doch möglich sein?

Schließlich dürfte es dort ja zu größeren und kleineren Dekomprimierungsfehlern kommen?

Und die aufwendigeren Dokumente (Word/Excel und Co) sollten doch auch merken können, ob da irgendwo was nicht stimmt?

Ich zitiere (fast) mal den WMP "Unerwartete Zeichenfolge entdeckt ... Datei konnte nicht geöffnet werden".

[stefan2005]

hi,
man könnte natürlich den Header jeder Datei auslesen und dann den Typ bestimmen.
Es sollte ja möglich sein zu prüfen, ob der Header dann wenigstens stimmt, und wird nicht in fast jeder Datei, wie JPEG oder MP3, auch eine Prüfsumme im Header angegeben ?

mfg,
stefan

[Der_Unwissende]

Hi,

Zitat:

Zitat von stefan2005

hi,
man könnte natürlich den Header jeder Datei auslesen und dann den Typ bestimmen.
Es sollte ja möglich sein zu prüfen, ob der Header dann wenigstens stimmt, und wird nicht in fast jeder Datei, wie JPEG oder MP3, auch eine Prüfsumme im Header angegeben ?

Nun ja, irgendwie klingt das ja nett, aber wie genau soll man am Fehler ein Prüfsumme mehr feststellen, als dass eine Datei defekt ist? Das geht imho nur, wenn die Datei eine Menge Prüfsummen enhält. Dann könnten diese für einzelne Abschnitte deren Korrektheit bestätigen. Auch hier gäbe es eine sehr sehr geringe Wahrscheinlichkeit, dass Fehler nicht erkannt werden (geht natürlich stark gegen 0).
Das eine Header in Takt ist bedeutet zudem auch nicht wirklich dass dies für die Daten gilt.
Wenn ich den Threadsteller richtig verstehe, soll ja schließlich gemerkt werden, wann wo ein Fehler auftritt und wie groß dieser ist. Das ist einfach nicht ohne weiteres möglich (wurde ja schon mehrfach gesagt).
Wie gut so etwas geht hängt einfach sehr stark vom Dateityp ab. Bei komprimierten Archiven gibt es ja häufig die Versuche diese zu reparieren (was nur teilweise klappt), aber wie man dass z.B. bei einem Tiff oder so merken sollte wäre mir nicht klar. Da fehlt die Überprüfung ob Daten valide sind. Natürlich gibt es dort für einen Teil der Variablen vorgeschriebene Grenzen, aber man weiß ja nicht ob das File standardkonform ist. Nach Tiff 6.0 Standard ist z.B. 16 Bit keine gültige Farbtiefe pro Layer.

Also so richtig pauschal kann man da einfach nicht helfen. Ob du etwas bei einer Datei retten kannst oder auch nur den Fehler findest hängt stark von der Datei ab und müsste für jeden Dateitypen einzelnd geprüft werden (wozu du alle erwarteten Filetypen und deren Aufbau kennen musst).

Gruß Der Unwissende

[himitsu]

da kann man wohl erstma nur heulen.

viele Dateien hab ich jainzwischen selber schon geprüft, aber bei knapp 600.000 der Kleinen und Großen ist das halt viel Aufwand.
prakisch ist ja, daß viele Dateien, wenn sie defekt sind das auch komplett sind und man somit bei 100% Unterschied zwischen 2 Dateien reht leicht entscheiden kannn, welche Version man behält.
Bei den Dateien mit 0% Fehler ist es ja noch einfacher ... man kann einfach irgendeine löschen.

Aber manche haben halt nur kleine Differenzen und da tauchen halt mal Dateien auf, die vom Gefühl her gleich sind, obwohl nachgewiesender Weise Unterschiede bestehen, also eine davon defekt sein muß.
Oder wo (z.B. bei Programmen) der Fehler nicht immer auffallen wird.