EMule-Bug bei Umstellung auf Sommerzeit !

**MightyKnife** · 30. March 2003, 16:13

Hi... zusammen

Ich arbeite zwar noch mit der Version Morph 0.26d - mir ist da ein Bug aufgefallen, von dem ich glaube, dass er in allen EMule-Versionen vorkommt !

Ich habe heute meinen Muli neu gestartet und - oh Wunder oh Wunder - er fing auf einmal an, alle Verzeichnisse neu zu scannen und die Dateien zu rehashen !?!

Eine Untersuchung des Quellcodes lässt darauf schliessen, dass der Muli ein Sommer-/Winterzeitproblem hat !

Scheinbar kommt er mit der Umstellung der Uhrzeit nicht richtig klar und behandelt daher alle Dateien nach der Zeitumstellung als neue Dateien !

Könnt ihr das bitte checken und an die Hauptentwickler weitergeben, falls dieses Problem in den aktuellen Versionen noch besteht ?

burner · 30. March 2003, 16:57

also ich weiß ja nich was du meinst aber bei mir war gar nix...
es lief so normal wie immer und ich hab [lovelace.9b]

Gotisch · 30. March 2003, 17:02

meine dateien hat er auch rehashed

MxM · 30. March 2003, 17:11

das könnte einiges erklären, wenn sich durch blosses zeitumstellen der hash verändert. ich persönlich halte das für humbug

**Usul** · 30. March 2003, 17:22

Der Hash ändert sich natürlich nicht durch die Zeitumstellung. Aber ich kann mir denken, woran es liegt. Emule muß die Datei neu hashen, wenn sich etwas an ihr geändert hat. Und woran kann man erkennen, ob sich eine Datei geändert hat? Natürlich am Inhalt, aber Emule kann sich natürlich nicht den Inhalt der ganzen Datei merken, also quasi die Datei kopieren. Eine andere Möglichkeit wäre, man hasht die Datei und merkt sich, wann die Datei gehasht wurde. Windows (genauer das Dateisystem) führt bei jeder Datei Buch, wann sie zuletzt geändert wurde. Wenn das letzte Änderungsdatum ein anderes ist wie zu dem Zeitpunkt, wo gehasht wurde, hat wohl jemand anderes daran herumgepfuscht -> neuer Hash erforderlich. Wenn Emule selbst darauf zugreift, kann es natürlich diese Änderungen sich merken und muß nicht neu hashen. Und ich denke mal, das Emule bei so einem Zeitsprung von einer Stunde einfach irgendwie durcheinanderkommt und deswegen neue hashen muß. Wie gesagt, nur ne Theorie, aber möglich.

**MightyKnife** · 30. March 2003, 20:04

Also das eigentliche Problem liegt darin, wie EMule versucht zu erkennen, ob sich eine Datei geändert hat.

Auf der Festplatte ist das Änderungsdatum der Datei unabhängig von Sommer-/Winterzeit gespeichert.
In der known.met ist die Uhrzeit der letzten Änderung ebenfalls gespeichert - und zwar nach die Umrechnung in Sommer/Winterzeit !

Für den Vergleich, ob sich die Datei geändert hat, wird das auf der Festplatte gespeicherte Datum zuerst durch die Windows-Routine gejagt, die Sommer/Winterzeit draufaddiert, und dann mit dem Datum in dem Known.met verglichen. Das geht dann natürlich in die Hose, da der auf der Festplatte gespeicherte Wert fest ist und da nicht mehr die Stunde für Sommer/Winterzeit draufaddiert werden darf !

Der Wert unterscheidet sich dann natürlich in dem Moment von dem gespeicherten Datum, wo die Windows-Routine anders draufaddiert - und schon ist die Datei "unterschiedlich" und muss neu gehasht werden.

Hier der zugehörige Codeschnipsel:

Datei: SharedFileList.cpp
Funktion: void CSharedFileList::AddFilesFromDirectory(char* directory);
Codezeilen:

CTime lwtime;
ff.GetLastWriteTime(lwtime);
uint32 fdate = mktime(lwtime.GetLocalTm());
CKnownFile* toadd = filelist->FindKnownFile(ff.GetFileName().GetBuffer(),fdate, (uint32)ff.GetLength());

=> Erst Änderungsdatum der Datei von der Platte holen, dann umwandeln, dann in FindKnownFile zum Vergleich reinstecken...

Datei: KnownFileList.cpp
Funktion: CKnownFile* CKnownFileList::FindKnownFile(char* filename,uint32 in_date,uint32 in_size);
Codezeilen:

if (ElementAt(i)->GetFileDate() == in_date && ...

... und dann mit dem gespeicherten Datum vergleichen.

Tja, schade aber auch

Richtig wäre es, nicht die umgerechneten Daten zu vergleichen, sondern ohne irgendwelche Umrechenroutinen zu arbeiten und das Roh-Datum zu speichern und zu vergleichen...

**MightyKnife** · 30. March 2003, 20:18

Kleiner Nachtrag:

Der Fehler lässt sich ganz einfach beheben, wenn man aus

uint32 fdate = mktime(lwtime.GetLocalTm());

die Zeile

uint32 fdate = mktime(lwtime.GetGmtTm());

macht. Dann wird nicht mehr umgerechnet und alles funktioniert ohne rehashen.

budman · 30. March 2003, 23:35

Cooler tip, Danke!

Hatte das heute auch schon, hat aber offengestanden nicht lange gedauert, deshalb hab ichs gar nicht wahrgenommen!

Gruss Bud

**vorlost** · 31. March 2003, 08:22

@MightyKnife:

Also Deine Lösung verändert die Uhrzeit die gespeichert wird.
Muss dann nicht auch die Zeit mit der verglichen wird geändert werden ???

in LoadPartFile:
// check date of .part file - if its wrong, rehash file
CFileStatus filestatus;
m_hpartfile.GetStatus(filestatus);
if (date != mktime(filestatus.m_mtime.GetLocalTm())){

in das hier geändert werden ???
if (date != mktime(filestatus.m_mtime.GetGmtTm())){

Weiterhin frage ich mich ob die GetGmtTm sich nicht ebenfalls bei der Umstellung Winterzeit/Sommerzeit ändert.
Und das Problem somit bei der nächsten Umstellung dann trotzdem wieder auftritt...
Eigentlich sollte eine andere Zeitzone ja ebenfalls von der Zeitumstellung betroffen sein und nicht nur Deutschland, oder habe ich da etwas falsch verstanden ?

**MightyKnife** · 31. March 2003, 20:00

Zitat:

Zitat von vorlost

@MightyKnife:

Also Deine Lösung verändert die Uhrzeit die gespeichert wird.
Muss dann nicht auch die Zeit mit der verglichen wird geändert werden ???

in LoadPartFile:
// check date of .part file - if its wrong, rehash file
CFileStatus filestatus;
m_hpartfile.GetStatus(filestatus);
if (date != mktime(filestatus.m_mtime.GetLocalTm())){

in das hier geändert werden ???
if (date != mktime(filestatus.m_mtime.GetGmtTm())){

Also erstmal: Meine Lösung verändert nicht die Uhrzeit, die gespeichert wird, sondern sie interpretiert die bereits gespeicherte Zeit anders - d.h. in der Known.met wird nix geändert. (oder hab ich da jetzt was falsch verstanden)

Die Änderung, die ich vorgeschlagen habe, betrifft die fertigen Dateien. Was du nun vorschlägst betrifft die .part-Dateien, die noch nicht fertig sein.
Also würde ich sagen: ja, ich glaube das müsste auch geändert werden.

Zitat:

Zitat von vorlost

Weiterhin frage ich mich ob die GetGmtTm sich nicht ebenfalls bei der Umstellung Winterzeit/Sommerzeit ändert.
Und das Problem somit bei der nächsten Umstellung dann trotzdem wieder auftritt...
Eigentlich sollte eine andere Zeitzone ja ebenfalls von der Zeitumstellung betroffen sein und nicht nur Deutschland, oder habe ich da etwas falsch verstanden ?

Das weis ich auch nicht so genau. In der Hilfe konnte ich bis jetzt noch nix über Sommer-/Winterzeit finden. Ich glaube jedoch nicht, das alle Länder der Zeitzone GMT+1 Sommer/Winterzeit haben. Gibt's das z.B. in Afrika ? Ich glaub nicht. Daher glaube ich, dass die GMT von der Sommer-/Winterzeit unabhängig ist. Will ich aber nicht die Hand für ins Feuer legen.

Moment, ich werf mal nen Blick in die Hilfe... (kram wühl such)

Vielleicht kann man aber auch was besseres mit dem Item tm_isdst der tm-Struktur machen, die der Funktion mktime übergeben wird. Die hat glaube ich Auswirkungen darauf, ob die Sommerzeit ("Daylight Saving Time, DST") aktiv ist oder nicht. Kenn ich mich aber auch (noch) nicht so aus. Müsste ich mal bei Gelegenheit antesten.

**MightyKnife** · 31. March 2003, 20:16

Zitat:

Zitat von vorlost

Weiterhin frage ich mich ob die GetGmtTm sich nicht ebenfalls bei der Umstellung Winterzeit/Sommerzeit ändert.
Und das Problem somit bei der nächsten Umstellung dann trotzdem wieder auftritt...
Eigentlich sollte eine andere Zeitzone ja ebenfalls von der Zeitumstellung betroffen sein und nicht nur Deutschland, oder habe ich da etwas falsch verstanden ?

Hier ich hab was gefunden:

In der Hilfe zur "tm"-Struktur heisst es:

tm_isdst: Positive if daylight saving time is in effect; 0 if daylight saving time is not in effect; negative if status of daylight saving time is unknown.

Wenn ich nun in die Hilfe der Funktion "CTime::GetGmtTm" reinschaue, dann steht da:

Return Value tm_isdst: Always 0

Das würde bedeuten, die von GetGmtTm zurückgelieferte Zeit, berechnet aufgrund der UTC, ist unabhängig von Sommer-/Winterzeit.
Passt das ?

**MightyKnife** · 31. March 2003, 20:23

[quote="MightyKnife"]

Zitat:

Zitat von vorlost

Weiterhin frage ich mich ob die GetGmtTm sich nicht ebenfalls bei der Umstellung Winterzeit/Sommerzeit ändert.
Und das Problem somit bei der nächsten Umstellung dann trotzdem wieder auftritt...
Eigentlich sollte eine andere Zeitzone ja ebenfalls von der Zeitumstellung betroffen sein und nicht nur Deutschland, oder habe ich da etwas falsch verstanden ?

Hier ich hab was gefunden:

In der Hilfe zur "tm"-Struktur heisst es:

tm_isdst: Positive if daylight saving time is in effect; 0 if daylight saving time is not in effect; negative if status of daylight saving time is unknown.

Wenn ich nun in die Hilfe der Funktion "CTime::GetGmtTm" reinschaue, dann steht da:

Return Value tm_isdst: Always 0

Das würde bedeuten, die von GetGmtTm zurückgelieferte Zeit, berechnet aufgrund der UTC, ist unabhängig von Sommer-/Winterzeit.
Passt das ?

Edit: Ach ja, die Hilfe von void _tzset( void ); gibt glaube ich auch noch Aufschlüsse über den Unterschied von UTC und LocalTime.

**MightyKnife** · 2. April 2003, 19:49

Wie ich jetzt feststellen musste, reichten beide Änderungen noch nicht aus, um EMule auf UTC umzustellen.

Zusätzlich muss noch folgende Änderung gemacht werden:

Datei: KNOWNFILE.CPP
Routine: bool CKnownFile::CreateFromFile(char* in_directory, char* in_filename)

Zeile

date = fileinfo.st_mtime;

muss geändert werden in

date = mktime (gmtime (&fileinfo.st_mtime));

Ansonsten werden die Dateien beim Neu-Laden mit dem falschen Datum gehasht !

Aber ansonsten scheint es zu funktionieren !

Ähnliche Themen: EMule-Bug bei Umstellung auf Sommerzeit !