Find all Duplicate Version 2.0 - Seite 2

Fritzclaaren · 03.04.2005, 21:21

Hallo Jobia,

vielen Dank für diese fundierte Erklärung!!!

Happy Landings
wünscht weiterhin
Fritz

Dragon45 · 03.04.2005, 22:25

Nabend,

hab das Proggi zwar heute morgen geladen, aber noch nicht genutzt. Gott sei Dank wohl

Danke für die Erklärungen zur "Problematik" - Hab mir wohl einige Probleme erspart mit dem Zögern der Installation!

LG

Rainer Hofmann · 04.04.2005, 07:33

Putzig ! Ich hatte die Frage im Jahr 2003 mal gestellt nach dem zur Speichentlastung dieses Programm in französischen Foren heiss empfohlen wurde. Habe es damals auch laufen lassen , es wurden viele "doppelte" Texturen entfernt ohne das es im FS2002 zu spüren war . Im FS9 habe ich es nicht versucht und gebe Hans und Jobia völlig recht .
Man sollte den FS9 so lassen wie er ist !

dimiwi · 04.04.2005, 10:47

Auch meine Meinung und danke für die Erklärung von JOBIA.

JOBIA · 04.04.2005, 20:03

Rainer das Problem ist im FS2002 im Prinzip das selbe. Nur damals wurden z.B bei Landclasscenerien selten eigene Texturen eingesetzt. Auch existierte dort das Speicherleck nicht. Von daher hätte man hier kein Absturz bei LCs erlebt, allenfalls wenn man eine LC Scenery mit eigenen Texturen gehabt hätte eine andere Optik.

Da es ja um doppelte Texturen geht, kann man zu 90% davon ausgehen, dass man die Textur einmal im Addon Texturordner findet und einmal im Haupttexturordner des FS. Löscht man die Textur im Addon, dann funktioniert das Addon in der Regel trotzdem, da es dann auf den Haupttexturordner zugreift.

Das funktioniert aber nicht immer.

Das Problem an der Geschichte ist aber, das die Textur im Addon und im Haupttexturordner eine verschiedene Optik haben können.

Das Addon funktioniert ev. ist aber hinsichtlich Optik verändert.

Z.B kann man den FS Runwaycode in der Scenery nutzen, die zugehörige Defaulttextur findet der FS im Haupttexturordner. Manchen Addon Designern gefällt das nicht, sie bauen eine eigene Textur mit identischen Namen in Ihren Texturordner ein. Dann greift der Runwaycode jetzt nicht mehr auf die Textur im Haupttexturordner zu, sondern auf die bessere des Addons im eigenen Texturordner.

Löscht Du jetzt diese Textur dann funktioniert diese Runway wieder mit der Defaulttextur. Das bedeutet es bleibt eine funktionsfähige Scenery aber mit schlechterer Optik.

Wie gesagt das ist eines der Beispiele neben denen die ich zuvor geschildert habe.

Da ich davon ausgehe, das Ihr nicht ständig alle Addons überwachen wollt würde ich sagen lasst lieber die Finger davon.

Ev. habt Ihr Glück und keine Abstürze, aber es ist nicht gewährleistet, dass euer Addon so aussieht, wie es der Produzent programmiert hat.

Michael45 · 04.04.2005, 20:20

Wenn zur Ermittlung ob Dateien `identisch` sind, folgende Kriterien herangezogen werden:

1. Vergleiche Namen
2. Vergleiche Grösse
3. Vergleiche Inhalt (binary check = Prüfsumme)

sollte das eigentlich nicht vorkommen.

Michael

JOBIA · 04.04.2005, 20:43

Zu

Zitat:

Original geschrieben von Michael45
Wenn zur Ermittlung ob Dateien `identisch` sind, folgende Kriterien herangezogen werden:

1. Vergleiche Namen
2. Vergleiche Grösse
3. Vergleiche Inhalt (binary check = Prüfsumme)

sollte das eigentlich nicht vorkommen.

Michael

Natürlich ist das eine Methode um festzustellen ob Dateien identisch sind oder nicht.

Nur schau mal in Texturordner von Addons rein. Da kommen doch schon mal tausend und mehr Texturen zusammen.

Man müsste die Suchergebnisse zusätzlich mit dieser Methode untersuchen. Viel zu aufwendig.

Nur selbst das ist noch nicht sicher genug um mal beim Beispiel Landclass zu bleiben.

Sobald ein Texturordner angelegt wurde kommt es beim löschen einer eindeutig als Kopie einer Defaulttextur identifizierten Textur zum Speicherleck.

Wenn das Tool so intellegent wäre, dass es nicht nur nach doppelten Namen, sondern auch zusätzlich kontrolliert ob es sich dabei um doppelten Bytecode handelt, wäre hier der Crash vorproduziert.

Michael45 · 04.04.2005, 21:07

Zitat:

Wenn das Tool so intellegent wäre, dass es nicht nur nach doppelten Namen, sondern auch zusätzlich kontrolliert ob es sich dabei um doppelten Bytecode handelt, wäre hier der Crash vorproduziert.

Siehe 3.

Die Chance, dass es trotz einer identischen Prüfsumme 2 unterschiedliche Inhalte sind. ist bei einem Image file vermutlich > 1: 100.000.000. Wahrscheinlich würde man eher im Lotto gewinnen, als dass dieser Fall eintritt.

Michael

JOBIA · 05.04.2005, 06:14

Das hast Du jetzt aber zum Schluss ganz falsch verstanden gehabt. Es geht hier nicht darum das ich irgendeinen Vergleich zweier Dateien anzweifele.

Logisch wenn der Bytecode einer Textur identisch ist, die Datei den selben Namen trägt, dass sie dann auch später wenn sie zugewiesen wird absolut identisch aussehen wird.

Das ist doch nicht das Thema.

Was ich sagen will, ist das selbst dann wenn man sichergestellt hat das Texturdateien in zwei verschiedenen Pfaden 100%tig identisch sind, nicht einfach eine der beiden Texturen löschen darf.

Genau darum ging es in dem Thread. Das löschen doppelter Texturen.

Es ist sehr gefährlich Texturen identischen Namens zu löschen wenn sie vom Bytecode nicht identisch sind. (sie tragen den selben Namen, sehen aber anders aus).

Weiterhin ist es genau so gefährlich Texturen identischen Namens zu löschen selbst wenn sie 100% tig identisch sind also optisch gleich aussehen.

Kommt halt auf die zuweisende Scenerytechnik an ob Gefahr in jedem Fall besteht.

Ich vermute Du hast mein Landclassbeispiel oben nicht verstanden und bist darüber gestolpert.

Daher ein Beispiel. Die Default LC Texturen sind bei mir in folgendem Pfad zu finden:

E:\FS2004\Scenery\World\texture

Auf diese globalen Texturen greift das Default Landclassfile des FS2004 zu.

Installiert man jetzt LC Addons als eigenständige Scenery """"ohne eigenen lokalen Texturordner""""" dann greifen diese LC Addons auf die Landclasstexturen in oben erwähnten globalen Texturordner zurück.

Erzeugt man zum Landclassaddon einen eigenen """"leeren"""" lokalen Texturordner dann kommt es zum Speicherleck.

Der FS2004 interpretiert hier irgendetwas falsch. Er sieht aha es ist ein eigener lokaler Texturordner da, dann nehme ich doch mal die Landclasstexturen aus diesem lokalen Ordner. Die müssen technisch bedingt die selben Namen haben wie die in oben erwähnten globalen Pfad, sonst funktioniert es nicht.

Aber ich erwähnte, dass der geschaffene Texturordner leer ist. Der FS merkt, oh da sind ja keine Texturen also muss ich doch in den globalen LC Texturordner schauen, also lädt er sie von dort.

Bei einer LC Scenery ist es aber so das während des Fluges ständig neue LC Informationen nachgeladen werden.

Der FS2004 schaut jetzt zunächst mal nach wurde denn schon aus meinem lokalen Texturordner etwas geladen.

Nein, denn der war ja leer. Das dumme ist, er ignoriert jetzt die ev. bereits geladene Textur des globalen Texturordners. Er lädt die benötigte Textur erneut.

So geht das Spielchen immer weiter bis die Auslagerungsdatei überläuft und der FS crasht. Das ganze kann man sehr schön mit Landclasstestscenerien simulieren.

Das zunächst zum Crash Problem wie es entsteht.

Jetzt soll sich der Kreis zu den doppelten Texturen schliessen.

Natürlich sollte mittlerweile jeder wissen, das man keinen leeren Texturordner haben sollte.

Aber es macht natürlich hin und wieder Sinn, dass man einen eigenen Texturordner bei Landclasscenerien hat.

Da wäre z.B die ATP das Beispiel.

Dort möchte man anders aussehende lokale Landclasstexturen nutzen.

Also legt man einen eigenen lokalen Texturordner an.

Die Speicherleckgefahr ist gegeben sobald eine in dem Landclassfile zugewiesen Textur fehlt. Das vermeidet man natürlich indem man darauf pingelig achtet, dass die zugewiesenen Texturen auch vorhanden sind.

Hier kommen jetzt also die lokalen LC Texturen rein.

Diese anders aussehenden lokalen Texturen müssen aber identischen Namen haben wie die im globalen Ordner.

Mit einer reinen Suche nach doppelten Namen wird man also Texturen im lokalen und globalen Texturpfad finden die von Namen identisch sind.

Von der Optik weichen sie ab.

Löscht man jetzt einfach Texturen kommt es zum Crash des FS.

OK wir sind schlau, wir suchen nicht nur stur nach Namen wir vergleichen auch den Dateninhalt also z.B den Bytecode der doppelt gefundenen Texturen. Wir stellen fest, ok sie haben identische Namen aber wohl verschiedenen Dateninhalt.

Wir sind jetzt also so schlau, dass wir wissen, wir dürfen hier nicht löschen, weil erstens die Optik des Addons nicht passen würde und weil wir ein Speicherleck produzieren.

Wenn das Tool dieses alles berücksichtigen würde, dann hätten wir bis hierhin fast ausgesorgt. Aber nur fast.

Denn wenn ein Addonproduzent der Optik wegen eigene Texturen einsetzen möchte, dann gibt es Fälle wo er nur ein paar wenige Texturen austauschen möchte, der Rest soll Defaultoptik behalten.

Da aber sobald ein eigener lokaler LC Texturordner existiert """alle"""" im LC File zugewiesenen Texturen (auch die die keine andere Optik haben sollen) hier auch vorhanden sein müssen, wird man Texturen finden die im Namen mit dem globalen Pfad identisch sind im Bytecode abweichen, aber auch welche die von Namen und vom Bytecode identisch sind. Also 100% tige Doubletten.

Selbst wenn dieses Tool nur die 100% identischen Texturen als löschbar ausweist, darf man sie in diesem Fall nicht löschen sonst hat man das Speicherleck.

Möchte man eine LC Scenery wie oben realisieren, kann man zwar konstruktionsbedingt diese Problematik beheben nur das macht nicht jeder Designer.

Ich selbst habe obige Konstellation schon bei Addons (nicht bei der ATP) gesehen.

JOBIA · 05.04.2005, 06:15

Von daher kann man nicht mit einem Tool nach doppelten Dateien suchen und diese einfach löschen selbst wenn sie wirklich 100% tig identisch sind.

Es ist einfach zu gefährlich.

Auch greift nicht jede Scenerytechnik auf einen globalen Texturpfad zurück, wenn in eimem lokalen Pfad eine 100%tige Kopie gelöscht wird.

Auch hier besteht dann eine Gefahr.

Das sollten meine Aussagen rüberbringen, man kann nie gefahrlos Texturen mit identischen Namen löschen egal ob der Bytecode nun abweicht oder nicht.

Klar es gibt Konstellation wo man das machen kann. Nur das weis kein Tool welches die Belange speziel des FS2004 nicht kennt.

03.04.2005, 22:25	#12
Dragon45 Hero Registriert seit: 15.06.2001 Beiträge: 810	Nabend, hab das Proggi zwar heute morgen geladen, aber noch nicht genutzt. Gott sei Dank wohl Danke für die Erklärungen zur "Problematik" - Hab mir wohl einige Probleme erspart mit dem Zögern der Installation! LG ____________________________________ Patrick

04.04.2005, 07:33	#13
Rainer Hofmann Inventar Registriert seit: 20.11.2001 Beiträge: 2.379	Putzig ! Ich hatte die Frage im Jahr 2003 mal gestellt nach dem zur Speichentlastung dieses Programm in französischen Foren heiss empfohlen wurde. Habe es damals auch laufen lassen , es wurden viele "doppelte" Texturen entfernt ohne das es im FS2002 zu spüren war . Im FS9 habe ich es nicht versucht und gebe Hans und Jobia völlig recht . Man sollte den FS9 so lassen wie er ist ! ____________________________________ Einen schönen Tag noch Rainer Duo cum faciunt idem, non est idem (Wenn zwei das Gleiche tun , ist es noch lange nicht dasselbe)

03.04.2005, 21:21	#11
Fritzclaaren Veteran Registriert seit: 12.02.2004 Beiträge: 320	Hallo Jobia, vielen Dank für diese fundierte Erklärung!!! Happy Landings wünscht weiterhin Fritz

04.04.2005, 10:47	#14
dimiwi Hero Registriert seit: 03.06.2004 Beiträge: 924	Auch meine Meinung und danke für die Erklärung von JOBIA.

04.04.2005, 20:03	#15
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	Rainer das Problem ist im FS2002 im Prinzip das selbe. Nur damals wurden z.B bei Landclasscenerien selten eigene Texturen eingesetzt. Auch existierte dort das Speicherleck nicht. Von daher hätte man hier kein Absturz bei LCs erlebt, allenfalls wenn man eine LC Scenery mit eigenen Texturen gehabt hätte eine andere Optik. Da es ja um doppelte Texturen geht, kann man zu 90% davon ausgehen, dass man die Textur einmal im Addon Texturordner findet und einmal im Haupttexturordner des FS. Löscht man die Textur im Addon, dann funktioniert das Addon in der Regel trotzdem, da es dann auf den Haupttexturordner zugreift. Das funktioniert aber nicht immer. Das Problem an der Geschichte ist aber, das die Textur im Addon und im Haupttexturordner eine verschiedene Optik haben können. Das Addon funktioniert ev. ist aber hinsichtlich Optik verändert. Z.B kann man den FS Runwaycode in der Scenery nutzen, die zugehörige Defaulttextur findet der FS im Haupttexturordner. Manchen Addon Designern gefällt das nicht, sie bauen eine eigene Textur mit identischen Namen in Ihren Texturordner ein. Dann greift der Runwaycode jetzt nicht mehr auf die Textur im Haupttexturordner zu, sondern auf die bessere des Addons im eigenen Texturordner. Löscht Du jetzt diese Textur dann funktioniert diese Runway wieder mit der Defaulttextur. Das bedeutet es bleibt eine funktionsfähige Scenery aber mit schlechterer Optik. Wie gesagt das ist eines der Beispiele neben denen die ich zuvor geschildert habe. Da ich davon ausgehe, das Ihr nicht ständig alle Addons überwachen wollt würde ich sagen lasst lieber die Finger davon. Ev. habt Ihr Glück und keine Abstürze, aber es ist nicht gewährleistet, dass euer Addon so aussieht, wie es der Produzent programmiert hat.

04.04.2005, 20:20	#16
Michael45 Senior Member Registriert seit: 28.02.2005 Beiträge: 138	Wenn zur Ermittlung ob Dateien `identisch` sind, folgende Kriterien herangezogen werden: 1. Vergleiche Namen 2. Vergleiche Grösse 3. Vergleiche Inhalt (binary check = Prüfsumme) sollte das eigentlich nicht vorkommen. Michael

05.04.2005, 06:14	#19
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	Das hast Du jetzt aber zum Schluss ganz falsch verstanden gehabt. Es geht hier nicht darum das ich irgendeinen Vergleich zweier Dateien anzweifele. Logisch wenn der Bytecode einer Textur identisch ist, die Datei den selben Namen trägt, dass sie dann auch später wenn sie zugewiesen wird absolut identisch aussehen wird. Das ist doch nicht das Thema. Was ich sagen will, ist das selbst dann wenn man sichergestellt hat das Texturdateien in zwei verschiedenen Pfaden 100%tig identisch sind, nicht einfach eine der beiden Texturen löschen darf. Genau darum ging es in dem Thread. Das löschen doppelter Texturen. Es ist sehr gefährlich Texturen identischen Namens zu löschen wenn sie vom Bytecode nicht identisch sind. (sie tragen den selben Namen, sehen aber anders aus). Weiterhin ist es genau so gefährlich Texturen identischen Namens zu löschen selbst wenn sie 100% tig identisch sind also optisch gleich aussehen. Kommt halt auf die zuweisende Scenerytechnik an ob Gefahr in jedem Fall besteht. Ich vermute Du hast mein Landclassbeispiel oben nicht verstanden und bist darüber gestolpert. Daher ein Beispiel. Die Default LC Texturen sind bei mir in folgendem Pfad zu finden: E:\FS2004\Scenery\World\texture Auf diese globalen Texturen greift das Default Landclassfile des FS2004 zu. Installiert man jetzt LC Addons als eigenständige Scenery """"ohne eigenen lokalen Texturordner""""" dann greifen diese LC Addons auf die Landclasstexturen in oben erwähnten globalen Texturordner zurück. Erzeugt man zum Landclassaddon einen eigenen """"leeren"""" lokalen Texturordner dann kommt es zum Speicherleck. Der FS2004 interpretiert hier irgendetwas falsch. Er sieht aha es ist ein eigener lokaler Texturordner da, dann nehme ich doch mal die Landclasstexturen aus diesem lokalen Ordner. Die müssen technisch bedingt die selben Namen haben wie die in oben erwähnten globalen Pfad, sonst funktioniert es nicht. Aber ich erwähnte, dass der geschaffene Texturordner leer ist. Der FS merkt, oh da sind ja keine Texturen also muss ich doch in den globalen LC Texturordner schauen, also lädt er sie von dort. Bei einer LC Scenery ist es aber so das während des Fluges ständig neue LC Informationen nachgeladen werden. Der FS2004 schaut jetzt zunächst mal nach wurde denn schon aus meinem lokalen Texturordner etwas geladen. Nein, denn der war ja leer. Das dumme ist, er ignoriert jetzt die ev. bereits geladene Textur des globalen Texturordners. Er lädt die benötigte Textur erneut. So geht das Spielchen immer weiter bis die Auslagerungsdatei überläuft und der FS crasht. Das ganze kann man sehr schön mit Landclasstestscenerien simulieren. Das zunächst zum Crash Problem wie es entsteht. Jetzt soll sich der Kreis zu den doppelten Texturen schliessen. Natürlich sollte mittlerweile jeder wissen, das man keinen leeren Texturordner haben sollte. Aber es macht natürlich hin und wieder Sinn, dass man einen eigenen Texturordner bei Landclasscenerien hat. Da wäre z.B die ATP das Beispiel. Dort möchte man anders aussehende lokale Landclasstexturen nutzen. Also legt man einen eigenen lokalen Texturordner an. Die Speicherleckgefahr ist gegeben sobald eine in dem Landclassfile zugewiesen Textur fehlt. Das vermeidet man natürlich indem man darauf pingelig achtet, dass die zugewiesenen Texturen auch vorhanden sind. Hier kommen jetzt also die lokalen LC Texturen rein. Diese anders aussehenden lokalen Texturen müssen aber identischen Namen haben wie die im globalen Ordner. Mit einer reinen Suche nach doppelten Namen wird man also Texturen im lokalen und globalen Texturpfad finden die von Namen identisch sind. Von der Optik weichen sie ab. Löscht man jetzt einfach Texturen kommt es zum Crash des FS. OK wir sind schlau, wir suchen nicht nur stur nach Namen wir vergleichen auch den Dateninhalt also z.B den Bytecode der doppelt gefundenen Texturen. Wir stellen fest, ok sie haben identische Namen aber wohl verschiedenen Dateninhalt. Wir sind jetzt also so schlau, dass wir wissen, wir dürfen hier nicht löschen, weil erstens die Optik des Addons nicht passen würde und weil wir ein Speicherleck produzieren. Wenn das Tool dieses alles berücksichtigen würde, dann hätten wir bis hierhin fast ausgesorgt. Aber nur fast. Denn wenn ein Addonproduzent der Optik wegen eigene Texturen einsetzen möchte, dann gibt es Fälle wo er nur ein paar wenige Texturen austauschen möchte, der Rest soll Defaultoptik behalten. Da aber sobald ein eigener lokaler LC Texturordner existiert """alle"""" im LC File zugewiesenen Texturen (auch die die keine andere Optik haben sollen) hier auch vorhanden sein müssen, wird man Texturen finden die im Namen mit dem globalen Pfad identisch sind im Bytecode abweichen, aber auch welche die von Namen und vom Bytecode identisch sind. Also 100% tige Doubletten. Selbst wenn dieses Tool nur die 100% identischen Texturen als löschbar ausweist, darf man sie in diesem Fall nicht löschen sonst hat man das Speicherleck. Möchte man eine LC Scenery wie oben realisieren, kann man zwar konstruktionsbedingt diese Problematik beheben nur das macht nicht jeder Designer. Ich selbst habe obige Konstellation schon bei Addons (nicht bei der ATP) gesehen.

05.04.2005, 06:15	#20
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	Von daher kann man nicht mit einem Tool nach doppelten Dateien suchen und diese einfach löschen selbst wenn sie wirklich 100% tig identisch sind. Es ist einfach zu gefährlich. Auch greift nicht jede Scenerytechnik auf einen globalen Texturpfad zurück, wenn in eimem lokalen Pfad eine 100%tige Kopie gelöscht wird. Auch hier besteht dann eine Gefahr. Das sollten meine Aussagen rüberbringen, man kann nie gefahrlos Texturen mit identischen Namen löschen egal ob der Bytecode nun abweicht oder nicht. Klar es gibt Konstellation wo man das machen kann. Nur das weis kein Tool welches die Belange speziel des FS2004 nicht kennt.

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)