Problem mit Dateialter und Zeitumstellung

[Patrick]

Hallo,

Ich habe ein Programm geschreiben, was die Dateien zweier Ordner über das "Geändert am"-Datum miteinander vergleicht und die Änderungen gegebenenfalls ausgleicht. Vorteil beim Backup machen: Ich kopiere nicht mehr alles, sondern nur noch Neues.

Jetzt ergibt sich aber immer zur Zeitumstellung folgendes Problem:
Mein Programm meinte nun alle Dateien auf meinem Stick wären älter als die Dateien auf meiner Platte. Will der mich verarschen? Das "Geändert am"-Datum verändert sich doch durch die Zeitumstellung nicht. Ich habe eine Datei um 15:00 Uhr geändert. Das ist vor und nach der Zeitumstellung so, daran darf sich nichts ändern. Mein Computer nudelt doch nicht nach der Zeitumstellung alle Datei-Daten durch und ändert das Datum um ne Stunde...

Damit bestimme ich das "Geändert am"-Datum einer Datei

Delphi-Quellcode:

  function GetLastModified(const Datei: string; out Value: TDateTime): Boolean;
  var dt : Integer;
  begin
    dt := FileAge(Datei);
    Result := dt >= 0;
    if Result then Value := FileDateToDateTime(dt);
  end;

[himitsu]

Das Datum im Dateisystem (also auf der Platte und dem USB-Stick) wird als GMT+0 abgespeichert, also ohne irgendwelche Zeitzonen- und Winter-/Sommerzeitinformationen.
Und ich vermute mal, daß bei einem der Datumsangaben, welche du ausließt diese "Zeitverschiebung" mit eingetrechnet wurde und beim anderem nicht, daher der Unterschied.

FileDateToDateTime(FileAge((...)) sollte den Wert als GMT+0 liefern (glaub ich), also könnte es daran liegen, daß das Dateim in dt incl. dieser Verschiebung vorliegt ... wie besorgst'n du dir dieses?


z.B. wurd bei den Dateumsangaben in TSearchResult (FindFirst/FindNext) die Zeitverschiebung des aktuell laufendem Systems schon beim uslesen mit zugerechnet.

Außerdem ist TDateTime ein ziehmlich ungenauer Datentyp, für solche Vergleiche ... der ist ja nur'n Double ... besser wöre es, wenn du die FileDate-Werte miteinander vergleichst, dat sind Integer und demnach etwas besser geeignet (abgesehn von den Rundungsfehlern beruhend auf'm Dateisystem)


PS: ich würde den Vergleich nicht nach dem Datum machen ... nich alle Dateisysteme besitzen die selbe Auflösung für's Datum, wobei es dann also zu Rundungsfehlern kommt ... hatte ich selber mal das Problem, obwohl Die Dateien das selbe datum haben sollten (da sie ja kopiert und somit "gleich" waren), gab es dennoch eine Differenz von bis zu 2 Sekunden (bei mir war'ns glaub'sch FAT16 und NTFS4).
Also entweder du vergleichst die Dateien direkt (Byte für Byte) oder per Hash (wobei man dort zur Sicherheit, bei gleichem Hash, auch nochmal Byte für Byte vergleichen sollte)

[Patrick]

Zitat:

FileDateToDateTime(FileAge((...)) sollte den Wert als GMT+0 liefern (glaub ich), also könnte es daran liegen, daß das Dateim in dt incl. dieser Verschiebung vorliegt ... wie besorgst'n du dir dieses?

Was "dieses"? Die Funktion "GetLastModified" ist doch in sich abgeschlossen. Ich gebe ihr die Datei als String und sie gibt mir das Datum.

Jetzt stellt sich mir halt die Frage, warum dieser Zeitfaktor auf die Dateien des Systems draufgerechnet wird, aber auf die Dateien meines Sticks nicht... Also mein Stick ist auf FAT formatiert, meine Platte aber auf NTFS... sch... Das sollte es sein.

Also an den "Byte für Byte"-Vergleich oder einen Hash-Vergleich habe ich auch schon gedacht, aber dann funktioniert das beidseitige Updaten nicht mehr. Das funktioniert bei Backups perfekt, aber nicht wenn ich zwei Ordner gegenseitig update...

[Christian Seehase]

Moin Patrick,

das Problem dürfte sein, dass FileAge FileTimeToLocalFileTime verwendet.

[Patrick]

Dann sollte ich wohl eine ander Funktion verwenden...
Hat jemand einen Vorschlag?

[marabu]

Hallo Patrick,

ich transferiere einen Teil meiner Arbeitsergebnisse per USB Festplatte zwischen meinem Büro- und Heimarbeitsplatz. Die Verzeichnisinhalte synchronisiere ich per XCOPY. Dieses Utility arbeitet nicht nach den Empfehlungen aus dem Hause Microsoft, aber für dich sollte das kein Problem sein:

Delphi-Quellcode:

function FileLastWritten(fn: TFileName): TDateTime;
var
  sr: TSearchRec;
  tzi: TTimeZoneInformation;
  lt, st: TSystemTime;
begin
  if FindFirst(fn, faAnyFile, sr) = 0 then
  begin
    GetTimeZoneInformation(tzi);
    FileTimeToSystemTime(sr.FindData.ftLastWriteTime, st);
    SystemTimeToTzSpecificLocalTime(@tzi, st, lt);
    Result := SystemTimeToDateTime(lt);
    FindClose(sr);
  end else Result := 0;
end;

Grüße vom marabu

[Corpsman]

@patrick

Hi ich war schon lange am überlegen so was für mich auch zu Programmieren, Rückst du deine Version vielleicht raus und ich kann mir die Arbeit sparen ?

Das Prob ist nämlich das der TotalComander den ich dafür bis jetzt immer benutzt habe zwar wunderbar tut, nur leider ist nach jedem Update mein Kompletter arbeitsspeicher voll ( Das Proggy gibt da wohl nicht mehr ales Korreckt frei ).

[Patrick]

@Marabu
Danke ich habe die Funktion ausgetauscht und werde es in Kürze testen!

@Corpsman
Was hättest du denn gerne, den Code oder nur das Programm?

[Corpsman]

@Patrick

Nun ich gebe zu, der Code wäre mir lieber, so könnte ich Dinge die ich anders lösen würde wie du gleich ändern.

Allerdings habe ich durchaus verständniss wenn du mir den Source nicht geben möchtest.

Dann würde ich mich eben nur als Tester sehen und dich andauernd mit Verbesserungsvorschlägen bombadieren ;) .

[Patrick]

Also, so wie das jetzt aussieht muss ich meine Funktion verwenden. Wenn ich die Dateien kopiert habe gibt meine Funktion ruhe, die von Marabu aber meint sie müsste wieder kopieren.

@Corpsman
Dann gib mir mal Ratschläge: Link
Wenn du mir deine Vorschläge nicht gefallen, dann kannst du den Code haben...

[himitsu]

Im Grunde kannst du auch ganz auf solche Funktionen wie von marabu verzichten, du mußt halt einfach nur das Datum von beiden Dateien mit der selben Funktion einlesen, dann ist es ja egal, ob da noch die Zeitverschiebung mit eingerechnet wurde, oder nicht ;)

[Patrick]

Muss ich jetzt zwischen den Zeilen lesen? :roll:

Was denkst du eigentlich was ich mache? Ich werde doch wohl die beiden dateien mit ein un der selben Funktion checken... Nur das Windows nach der Zeitumstellung in FAT eine andere DateiZeit hat als in NTFS. (Wenn die Dateien vorher die selben waren)

[Corpsman]

Hi Patrick,

Ohne das Programm gestartet zu haben ( Nur bei sichtung des Screenshots ) kann ich dir schon ein paar sachen die "Cooler" wären.

Die Angaben der Dateien sollten nicht Absolut sein, sonder eher bezogen auf die Beiden Ordner.

Bei mir z.b. würde das heisen das er nicht hinschreibt.

d:\Tools\Projects\Sample\Tricks\TXTFiles\Test.txt <- \\Corpsman2\d\Tools\Projects\Sample\Tricks\TXTfile s\Test.txt

sondern.

Sample\Tricks\TXTFiles\Test.txt <- Sample\Tricks\TXTfiles\Test.txt

Und in einer Caption die beiden hauptpfade einträgt.

Als nächstes wäre cool wenn dann alle -> und <- Pfeile untereinander stehen würden. so das dann auch die anderen Angaben immer untereinander ständen. Dies bedeutet wahrscheinlich das man bei der Checklistbox ein Owner draw fixed machen mus ;) oder eine ganze menge String operationen.

Testen Konnte ich dein Programm leider nicht, da jedesmal wenn ich auf das Netzwerklaufwerk zugreifen will er ne Exception wirft.

Was schon merkwürdig ist da es ja noch im Select Dialog ist. Es gibt jedesmal den Fehler. Bla Bla shell32.dll Bla bla

Ich hoffe du kannst damit was anfangen sonst folgen eben screnshoots oder weitere erklärungen.


Corpsman

[TeronG]

Zitat:

Zitat von Patrick

Muss ich jetzt zwischen den Zeilen lesen? :roll:

Nein .. nur hinter dem Vorhang bzw. hinter den Functionen .. Da du ja andere Ergebnisse hast macht deine Function intern scheinbar bei den verschiedenen Dateisystemen jeweils was anderes .. (stand so weit ich mich erinnern kann schon weiter oben oder?) ...
also gug doch z.B. mal was die da macht ..

(hoffe es war nicht wieder n Fehler zu tippen ohne den ganzen Threat nochmal gelesen zu haben :mrgreen: )