Hat eine Datei etwas eindeutiges?

[Dragon27]

Hallo,

ich wollte Fragen ob es irgendetwas gibt mit dem man feststellen kann ob eine Datei eine Kopie ist oder nicht....

Also z.B. Das Datum oder so...

Also praktisch ein Atribut was nur diese eine Datei hat und nicht die Kopie....

Vielleicht gibts dazu ja irgendeine function in Delphi?

Danke für die Antworten!!!

Gruß

Andy

[marabu]

Hallo Andy,

wenn du wissen willst, ob zwei Dateien den gleichen Inhalt haben, dann wäre ein digital finger print die Lösung. Suche mal in der code library oder im Internet nach md5.

Grüße vom marabu

[ichbins]

Er weiss ja dass die Dateien den selben Inhalt haben. Es geht ihm nur drum ob die eine Datei das Original und die andere die Kopie ist. IMHO lassen sich allerdings ALLE Eigenschaften der Datei fälschen. Du könntest allerdings die Position der Datei auf der Festplatte ermitteln (z.B.: Byte 23489244 - Byte 23503434). Wenn der User dann allerdings die Festplatte formatiert etc. is das auch nixmehr.

==> Geht nicht.

Der Kopierschutz von CDs funktioniert über bestimmte Eigenschaften des Dateisystems CDFS. (falsche Quersummen etc.)

[Dragon27]

Hallo,

ja also es soll jetrzt nicht direkt ein Kopierschutz werden aber ich habe mir gedacht dass vielleicht das Datum anders ist?
Kennt Ihr da was wie man das auslesen kann?

Gruß

Andy

[marabu]

Hallo Andy,

für dich am einfachsten könnte das hier sein:

Delphi-Quellcode:

uses
  SysUtils;

var
  dt: TDateTime;
begin
  dt := FileDateToDateTime(FileAge('filename.ext'));
end;

Frohe Weihnachten vom marabu

[ichbins]

Aber das Datum lässt sich ja auch einfach verändern. Mit setfiletime.

[tommie-lie]

Zitat:

Zitat von ichbins

Du könntest allerdings die Position der Datei auf der Festplatte ermitteln (z.B.: Byte 23489244 - Byte 23503434). Wenn der User dann allerdings die Festplatte formatiert etc. is das auch nixmehr.

Richtig, wenn der Benutzer das Dateisystem formatiert, dann findet man auch die Dateien nicht mehr...
Die physikalische Position der Datei ist in keinster Weise als Anhaltspunkt dafür zu nehmen. Zum einen kann eine Defragmentierung des Dateisystems die Cluster komplett anders anordnen, und zum anderen sind Dateisysteme für Random-Access Massenspeicher mit vielen zufälligen Schreib- und Lesezyklen nicht so aufgebaut, daß eine Datei immer in einem Stück auf der Platte liegt, sondern man die Datei in viele Cluster aufteilt, von denen der erste ganz am Anfang des Dateisystems, und der zweite ganz am Ende liegen kann. Außerdem werden je nach Größe der Datei freigewordene Cluster im Dateisystem recycled, löscht man also eine Datei am Anfang, kann eine andere Datei, die man zu einem späteren Zeitpunkt anlegt, in diesen Clustern liegen, und nicht einfach "hinten dran".

Zitat:

Zitat von Dragon27

Also praktisch ein Atribut was nur diese eine Datei hat und nicht die Kopie....

Den Dateinamen. Er ist die einzige High-Level-Eigenschaft, die in einem Dateisystem jede Datei exakt definiert, kein Dateiname existiert zweimal. Low-Level kommen dann noch der Index im Baum, die maskierten Einträge in derAllocation Bitmap oder die Pointer auf INodes dazu, je nachdem um welches Dateisystem es sich handelt.
Es gibt aber keine Möglichkeit, das Original von einer Kopie zu unterscheiden, wenn du das Original nicht kennst. Es gibt auch keine Möglichkeit, den Inhalt einer Original-CD und einer Kopie von ihr zu unterscheiden.

[Igotcha]

Da hänge ich mich doch mal dran ;-)

Ich stehe vor einem ähnlichen Problem, dann ich will die Dateien einer lokalen Installation von denen der "gültigen" Installationsdateien unterscheiden. Konkret habe ich einen "Autoupdater", der nachschaut, welche Dateien lokal vorliegen und diese dann ggf. mit Dateien vom Server überschreibt bzw. ergänzt.

Momentan benutze ich dazu einen Mix aus "Compile-Date" und Dateigröße. Ein kleiner Haken an der Sache ist, dass z.B. Textdateien kein "Compiledate" haben und ich diese nicht eindeutig identifizieren kann, sofern die Dateigröße lokal und auf dem Server identisch ist.

Gruß,
Igotcha

[Ratte]

Die Datein sind also unterschiedlich, ja? Diese Unterscheidung kannst du dann mit einem Hash lösen (z. B. MD5).

Schöne Weihnachten!
Ratte

[ichbins]

Nein, eben nicht :wall: Die Dateien haben genau den gleichen Inhalt, nur soll dann sicher zwischen Original und Kopie unterschieden werden.

@tommie-lie: sry, ich meinte defragmentieren und nicht formatieren... wie bin ich denn darauf gekommen? :gruebel:

[Khabarakh]

Zitat:

Zitat von ichbins

Nein, eben nicht :wall:

Wo liest du denn das heraus? Ich habe Igotchas Beitrag jedenfalls wie Ratte verstanden. Und ich glaube, dass so ziemlich jedes der vielen Synchronisierungsprogramme bei einem gleichen Hash aufhört und die Dateien als "gleich" abstempelt.

[Igotcha]

Zitat:

Zitat von Ratte

Die Datein sind also unterschiedlich, ja? Diese Unterscheidung kannst du dann mit einem Hash lösen (z. B. MD5).

Nein, kann ich in diesem Fall nicht ;-)

Mein "Autoupdater" ist nämlich zugleich "Launcher" meines Programms - sprich, der Anwender startet nicht das Hautprogramm direkt, sondern es wird der Launcher gestartet, dieser prüft Gleichheit von lokaler Installation zu Vorgabe auf Server und startet dann das Hauptprogramm.

Es ist aus meinem Empfinden für den Anwender unzumutbar, bei jedem Start des Programms z.B. 3 Minuten zu warten, bis alle lokalen Dateien durchgehasht wurden.

Da mein Programm modular aufgebaut ist, ist es in der Praxis chic, dass zur Neuinstallation nur der Launcher auf dem Clienten installiert sein muss. In der Datenbank auf dem Server ist hinterlegt, welches Modul welche Dateien in welcher Version benötigt und für welche Module der Anwender berechtigt ist. Loggt sich der Anwender nun in den Launcher ein, werden nur genau die Datei auf den Clienten kopiert (sofern nicht beriets in der richtigen Version vorhanden), die für diesen Anwender notwendig sind.

Löscht der Anwender aus Versehen oder bewußt eine Datei, oder verändert eine Datei, ist diese beim nächsten Programmstart wieder im Originalzustand auf dem Clienten vorhanden.

Wie gesagt benutze ich momentan folgende Informationen zur Identifikation einer Datei:

MD5(Compilationsdatum + Dateigröße)

Diese Information liegt zu jeder Datei in der Datenbank und wird mit dem ermitteltem Hash der lokalen Datei verglichen (das ist von der Performance her zumutbar).

Bei z.B. Textdateien gibt es aber kein Compilationsdatum und z.B. die Änderung eines Buchstabens in einer Textdatei würde somit nicht erkannt werden.

Gruß
Igotcha

[tommie-lie]

Zitat:

Zitat von Igotcha

Es ist aus meinem Empfinden für den Anwender unzumutbar, bei jedem Start des Programms z.B. 3 Minuten zu warten, bis alle lokalen Dateien durchgehasht wurden.

Normalerweise lädt man zusammen mit den Dateien auch die Hashes herunter und hinterlegt das Dateidatum zusammen mit den Hashes. Eine Änderung des Dateidatums und der -größe *könnte* beabsichtigt sein, in einem solchen Fall kann man meinetwegen auf Anfrage neu hashen, ansonsten zweifelt man die Integrität der Dateien an und weist darauf hin, daß es nicht ratsam ist, das Programm weiterhin zu benutzen, ohne die geänderten Daten neu herunterzuladen. Beim Starten lädt man lediglich die Hashes der Dateien auf dem Server herunter, vergleicht mit den lokalen Hashes aus dem Installationscache, unterscheiden sie sich, lädt man neu herunter, ansonsten lässt man's bleiben.
Damit stellst du sicher, daß das Programm zumindest nicht ohne weiteres verändert werden kann, z.B. von Viren infiziert wird, und hältst den Netzwerk-Traffic sowie die Reaktionszeit beim Programmstart gering.

[jfheins]

Imho solltest du, wenn du nicht gerade die Erstimplementierung eines Neulings verwendest, alle deine dateien locker innerhalb einer Sekunde gehasht bekommen ;) (MD5 schafft etwa ~170 MB pro Sekunde) Von daher würde ich dir raten, alle Dateien zu Hashen, Hash+Dateiname an den Server zu schicken, der dann sagen kann, was geändert werden muss ;)

[tommie-lie]

Zitat:

Zitat von jfheins

Von daher würde ich dir raten, alle Dateien zu Hashen, Hash+Dateiname an den Server zu schicken, der dann sagen kann, was geändert werden muss ;)

Aua. Nur weil es nicht dein Rechner ist, heißt es nicht, daß du über die Rechenzeit frei verfügen kannst. Es ist definitiv sinnvoll, die Hash-Werte zu cachen, wie beispielsweise in meinem Vorschlag. Rechenleistung und Arbeitsspeicher sind Dinge, die nicht verschwendet werden sollten, egal ob sie in inflationären Mengen zur Verfügung stehen, oder nicht. So sind deine 170MB/s schonmal ein vollkommen irrelevanter Wert, in der Praxis liefert die Festplatte die Daten nicht schneller als etwa 40MB/s. Wenn dann noch das I/O-System durch andere Prozesse ausgelastet ist, bricht die Transferleistung der Festplatte sehr gerne sehr schnell auf sehr niedrige Werte ein. Ähnliches gilt für die Prozessorleistung. Man ist mittlerweile nicht mehr der einzige, der auf einem System das Sagen hat, und so sollte man sich auch benehmen. Außerdem würde dein Verfahren *sämtliche* Entscheidungslast auf den Server verlagern. Sinnvoller ist es, die Clients die Arbeit erledigen zu lassen. Dann kann sich der Server darauf konzentrieren, in den allermeistne Fällen lediglich die Hashes bereitzustellen und nichts großartig zu rechnen, und die Handvoll Hashes lassen sich prima Cachen und schnell on-demand an den Client absetzen, als "Prozessor" würde da alles reichen, was Pointer kennt.

[Igotcha]

Also ich probiere das mal mit dem Hashen der Dateien.

Und selbstverständlich werden vom Server nur die Hashes der Dateien abgefragt - falls das bisher nicht so rübergekommen ist ;-)

Gruß
Igotcha