Entwickler-Ecke :: Thema anzeigen - Zeitumstellungsproblem

D. Annies - Di 28.10.08 10:21
Titel: Zeitumstellungsproblem

Hi, Delpher,

in meinem Programm arbeite ich mit zwei Laufwerken. Die Dateien, die verändert oder neu erstellt werden, können dann am Ende der Arbeit auf Nachfrage auf dem jeweils anderen Laufwerk gesichert werden (wie eine Synchronisation).

nach der Zeitumstellung passiert es lästigerweise, dass mein Programm alle gesicherten / zu sichernden Dateien als verändert erkennt - weil es ein anderer Zeitstempel ist - obwohl ich mit der Datei nichts gemacht habe (sie also nicht aufgerufen / verändert habe) - nur ein Zeitunterschied von einer Stunde wird angemeckert und dann ist die Datei neu zu sichern. Das möchte ich vermeiden, weil ja nichts verändert wurde.

Was ist da zu tun?

Gruß, Detlef

Logikmensch - Di 28.10.08 10:44

Ich kann nur empfehlen, nicht den Zeitstempel alleine dafür zu verwenden, ob eine Datei verändert wurde oder nicht. Besser ist es z.B. eine CRC32-Prüfsumme drüberlaufen zu lassen. Nur wenn die der Quelle und dem Ziel identische Prüfsummen haben, kann man fast 100%ig davon ausgehen, dass die Dateien identisch sind.

Delete - Di 28.10.08 10:48

Außerdem gibt es ja noch das Archiv-Attribut, wenn man auf Prüfsummen verzichten will.

D. Annies - Di 28.10.08 10:49

Dank dir erstmal, Namensvetter, ich melde mich wieder...
Gruß, Detlef

D. Annies - Di 28.10.08 12:20

Uff, uff, ich blicke noch nicht durch.

Hier ist mal der Code, mit dem ich entscheide, ob eine Datei zu sichern ist oder nicht.

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:

if fileexists(Pr_FileName) then
          begin
            if FileDateToDateTime(FileAge(Pr_FileName)) <> FileDateToDateTime(FileAge(existingfilename)) then
            begin
              erg := xmessagedlg('Soll    ' + pr_filename+ ' '+#13+ datetimetostr(filedatetodatetime(FileAge(Pr_Filename))) +#13+
                          'durch '   + existingfilename  + ' '+#13+ datetimetostr(filedatetodatetime(FileAge(ExistingFileName))) +#13+
                          ' ersetzt werden?', mtConfirmation, [mbYes, mbno, mbcancel], ['ja', 'nein', 'Abbrechen'], self.font);

              case erg of mryes    : CopyFile(PChar(ExistingFileName), PChar(Pr_FileName), FALSE);
                          mrcancel : raus := true;
              end;
            end;
          end

Ist so etwas leichter zu erkennen, was ich verändern / ergänzen muss?

Gruß, Detlef

Delete - Di 28.10.08 12:23

Hast Du mal das Archiv-Attribut geprüft?

D. Annies - Di 28.10.08 12:42

Uff, jetzt habe ich den folgenden Code (aus der Hilfe) gefunden: [aber keinen Plan]

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:

//Im folgenden Beispiel werden die Attribute einer Datei in eine Mengenvariable 
//gelesen. Anschließend werden die Kontrollkästchen im Dialogfeld mit den 
//Dateiattributen entsprechend aktiviert und das Dialogfeld geöffnet. Alle Änderungen, 
//die der Benutzer an den Attributen vornimmt, werden auf die Datei übertragen.

procedure TFMForm.Properties1Click(Sender: TObject);
var
  Attributes, NewAttributes: Word;
begin
  with FileAttrForm do
  begin
    FileDirName.Caption := FileList.Items[FileList.ItemIndex];
    { Überschrift des Feldes festlegen }
    PathName.Caption := FileList.Directory;
    { Verzeichnisname anzeigen }
    ChangeDate.Caption := 
      DateTimeToStr(FileDateToDateTime(FileAge(FileList.FileName)));
    Attributes := FileGetAttr(FileDirName.Caption);
    { Dateiattribute lesen }
    ReadOnly.Checked := (Attributes and faReadOnly) = faReadOnly;
    Archive.Checked := (Attributes and faArchive) = faArchive;
    System.Checked := (Attributes and faSysFile) = faSysFile;
    Hidden.Checked := (Attributes and faHidden) = faHidden;
    if ShowModal <> id_Cancel then  { Dialogfeld ausführen }
    begin
      NewAttributes := Attributes;
      { mit den ursprünglichen Attributen beginnen }
      if ReadOnly.Checked then
        NewAttributes := NewAttributes or faReadOnly
      else 
        NewAttributes := NewAttributes andnot faReadOnly;
      if Archive.Checked then
        NewAttributes := NewAttributes or faArchive
      else 
        NewAttributes := NewAttributes andnot faArchive;
      if System.Checked then 
        NewAttributes := NewAttributes or faSysFile
      else 
        NewAttributes := NewAttributes andnot faSysFile;
      if Hidden.Checked then 
        NewAttributes := NewAttributes or faHidden
      else 
        NewAttributes := NewAttributes andnot faHidden;
      if NewAttributes <> Attributes then { falls etwas geändert wurde... }
        FileSetAttr(FileDirName.Caption, NewAttributes);
         { ...die neuen Werte schreiben }
    end;
  end;
end;

Idee?

Delete - Di 28.10.08 12:59

Delphi-Quelltext

1:
2:

  if (FileGetAttr(Dateiname) and faArchive) = faArchive then
    ShowMessage('Archivattribut gesetzt');

D. Annies - Di 28.10.08 13:43

gut, aber eine showmessage verändert ja noch nichts. Was kann man denn am Archiv-Attribut überhaupt erkennen?

Delete - Di 28.10.08 14:04

Das Archiv-Attribut wird vom OS bei Dateiänderungen gesetzt.

Agawain - Di 28.10.08 14:20

hi

hier eine ausführliche Erklärung

http://de.wikipedia.org/wiki/Archivbit

Delete - Di 28.10.08 15:13

DeddyH hat folgendes geschrieben :

Das Archiv-Attribut wird vom OS bei Dateiänderungen gesetzt.

darauf würde ich mich aber auch nicht verlassen, da man dieses archivbit auch aus Anwendungen setzen und löschen kann. Nero löscht es zum beispiel, wenn die Dateiu gebrannt wurde.

Delete - Di 28.10.08 15:23

Das ist ja auch der angedachte Zweck dieses Attributs. Backupprogramme sollen es auswerten, die Datei ggf. sichern und das Attribut anschließend löschen.

D. Annies - Di 28.10.08 15:32

Vielen Dank erstmal! Nun dauerts nicht mehr lange bis zur Lösung.
So, jetzt habe ich den folgenden Code:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

if (FileDateToDateTime(FileAge(Pr_FileName)) <> FileDateToDateTime(FileAge(existingfilename)) and
               ((FileGetAttr(Pr_FileName) and faArchive) = faArchive) then
            begin
              erg := xmessagedlg('ArchivBit wurde gesetzt' +#13 +
                          'Soll    ' + pr_filename+ ' '+#13+ datetimetostr(filedatetodatetime(FileAge(Pr_Filename))) +#13+
                          'durch '   + existingfilename  + ' '+#13+ datetimetostr(filedatetodatetime(FileAge(ExistingFileName))) +#13+
                          ' ersetzt werden?', mtConfirmation, [mbYes, mbno, mbcancel], ['ja', 'nein', 'Abbrechen'], self.font);

// usw.

aber ich bekomme die Fehlermeldung:
Operator ist auf diesen Operandentyp nicht anwendbar.
(und die Warnung: ... plattformspezifisch [aber das ist ja nur eine Warnung])

Was ist noch falsch?

Delete - Di 28.10.08 15:38

Eine Klammer zu wenig:

Delphi-Quelltext

1:
2:

if (FileDateToDateTime(FileAge(Pr_FileName)) <> FileDateToDateTime(FileAge(existingfilename))) and
               ((FileGetAttr(Pr_FileName) and faArchive) = faArchive) then

So müsste es klappen. Die Warnung von wegen plattformspezifisch kannst Du getrost ignorieren, es sei denn, Du willst mit Kylix für Linux entwickeln.

D. Annies - Di 28.10.08 15:46

Hi, Deddy,

jo, habe ich auch gerade gesehen, dass in der ersten Bedingung eine äußere Klammer fehlte - nun denn mal (wieder) herzlichen Dank für deine (eure) Bemühungen!

Bis zum nächsten Mal,
Detlef A.

baka0815 - Di 28.10.08 16:53

Wie Lucky aber bereits gesagt hat, können auch andere Anwendungen das Archiv-Bit zurücksetzen.

Wenn Nero das macht, wie Lucky sagt, würden die Daten nicht mehr gesichert, sobald Nero die gebrannt hat (weil ja bereits von Nero "gesichert").

Auf der sicheren Seite wärst du (meiner Meinung nach), wenn du die Dateigröße und einen Hash (MD5, SHAx, etc.) miteinander vergleichst - dürfte dann nur länger dauern, da zu jeder Datei der Hash gebildet werden muss.

Delete - Di 28.10.08 17:02

DeddyH hat folgendes geschrieben :

Das ist ja auch der angedachte Zweck dieses Attributs. Backupprogramme sollen es auswerten, die Datei ggf. sichern und das Attribut anschließend löschen.

Das Problem ist nur, dass sich zwei Programme in die Quere kommen können, wenn sie sich auf das Archivbit verlassen.

Delete - Di 28.10.08 17:06

Was sagst Du mir das? Das ist Microsofts Idee gewesen.

Delete - Di 28.10.08 17:11

DeddyH hat folgendes geschrieben :

Was sagst Du mir das? Das ist Microsofts Idee gewesen.

Du bist im Moment greifbar -- Microsoft nicht. :mrgreen:

Delete - Di 28.10.08 17:12

Ja nee is klar :mrgreen:

D. Annies - Di 28.10.08 19:00

Lass dich nicht verkloppen, Deddy!

Delete - Di 28.10.08 19:29

Lass die Jungspunde erstmal in mein Alter kommen ;) Aber nun genug OT, gell?

Delete - Di 28.10.08 22:45

DeddyH hat folgendes geschrieben :

Lass die Jungspunde erstmal in mein Alter kommen ;) Aber nun genug OT, gell?

Jungspund? Meinst du mich? Ich bin mittler weile auch 34 Jahre alt.

Aber um noch was zum Thema beizutragen. Ich hatte mir mal ein Programm geschrieben, um Ordner zu synchronisieren, da habe ich mit MD5 Hashes gearbeitet. Das hat wunderbar funktioniert. Nachteil ist natürlich, dass das Bilden des Hashes eben Zeit braucht, aber eben auch sicherer ist. Eine Zeitumstellung kommt zwei mal im Jahr vor, aber was wenn die Uhr mal falsch geht? Dann hast du den Salat.

D. Annies - Mi 29.10.08 18:47

Danke, Lucky