[quote="Schrottie"]... so das ich in diesem Fall auf "Unterstützung aus Freiburg" angewiesen bin...
[/quote]
Autsch! Der Zaunpfahl hat weh getan!
[/quote]
Und inzwischen ist der Zaunpfahl ja auch nicht mehr nötig.
Ich habe das Vorhaben inzwischen [url=http://www.bischiweb-online.de/wp/logkopien-von-gc-entfernen/]komplett in die Tat umgesetzt[/url]. Und das ging am Ende einfacher und schneller als ich zunächst gedacht habe. Nachdem ich mir ein passendes Script zurechtgebaut hatte, war es nur mehr ein wenig Fleißarbeit. Kurz zusammengefasst lief das so:
Wenn man geolog/ocprop benutzt, dann hat man im geolog-Verzeichnis schön strukturiert alle Fund und DNF abgelegt, jeweils in eigenen Verzeichnissen. Darin wiederum ist für jeden Cache ein weiteres Unterverzeichnis, das ein paar Dateien enthält, die Angaben zum Cache und zum Log beinhalten. Sobald ein Log zu OC kopiert wird, gibt es für dieses Log eine weitere Datei. Nach dieser weiteren Datei suchte mein Script und wenn sie vorhanden war, dann wurde die GC-Logdatei entfernt, die Datei die den Cache beschreibt um alle Hinweise auf GC erleichtert und der Verzeichnisname geändert (normalerweise beinhaltet er den GC-Wegpunkt, außer eben bei OConly).
--> Zeitbedarf bei aktuell 3223 Fundlogs: Wenige Sekunden.
Anschließend mussten natürlich noch die Logs bei GC gelöscht werden, und dazu kommt man um Handarbeit nicht herum. Das Script hat jedoch alle betroffenen GC-Wegpunkte als Link in eine HTML-Datei geschrieben, so das ich diese Datei nur einmal komplett durchackern musste. Bei Fundlogs ging das verhätlnismäßig schnell, denn bei denen hat man ja im Listing oben rechts einen Link zum Log, den muss man dann nur aufrufen und das Logs löschen. Aktive caches habe ich dabei gleich auf die Ignoreliste geschoben, damit sie mir aus dem PQ fernbleiben. Einzig bei DNF-Logs klickt man etwas mehr, denn da muss man erst das "Listing-Logbook" aufrufen um das Log zu finden.
--> Zeitbedarf für 598 Fund- und 31 DNF-Logs: Grob geschätzt 3 Stunden, wobei ich das vormittags geacht habe, wo GC noch recht flott erreichbar ist. Einen kurzen Versuch nachmittags noch ein wenig zu löschen habe ich dann lieber abgebrochen, da werden die Server in Seattle deutlich langsamer.
Tja, blieb nur eines: Es ergab sich eine Differenz von 6 Fundlogs. Nach geolog-Statistik sollten da bei OC 805 Funde sein, bei OC selbst waren es aber nur 799. Wenn man nur wenige Funde hat, dann sollte auch das weniger ein Problem sein, aber jetzt 3223 Fundlogs gegen die 799 abzugleichen um die fehlenden zu lokalisieren ist schon heftig. Aber irgendwas ist ja immer und da ich nicht sicher sein konnte, das das Script da evtl. ein wenig Amok gelaufen ist, musste der Fehler gesucht werden. Naja, nach...
--> Zeitbedarf für die Fehlersuche: knapp 2 Stunden bis zur plötzlichen "Erleuchtung"
...eben diesen 2 Stunden fiel es mir dann wie Schuppen aus den nicht vorhandenen Haaren: Listingrecycling. Die Pein aller Geocacher, außer den fünf oder sechs die das tatsächlich schön finden. Es gibt da hier in der Gegend ein Event, dessen Listing immer wieder neu genutzt wird, obwohl es mit exakt dem gleichen Aufwand auf jeweils neu angelegt werden könnte. Und weil dieses Listing jeden Monat aufs neue alle Scripte und dergleichen durcheinander würfelt, habe ich irgendwann damit begonnen dieses Event mit kleineren Tricks komplett aus dem "Statisticworkflow" zu entfernen. Damit liegen die 6 Attendlogs hier lokal zwar vor, bei OC sind sie aber schon lange wieder gelöscht. Tja, und damit war auch dieser Fehler entdeckt.
Zusammenfassend bleibt zu sagen: Wenn man nicht gerade Streß mit Listingrecycling hat und darüber hinaus auch vormittags an die Sache gehen kann, dann ist so eine Aktion recht flott erledigt.
Und noch etwas fällt dadurch auf, wobei das aber auch dem Umstand geschuldet ist, das ich sowohl zu Hause als auch in meinen bevorzugten Urlaubsregionen viel OC finden kann: Nahezu exakt ein Viertel (805:2417[:1]) meiner Funde ist bei OC gelistet. Das ist schon ein echt guter Schnitt, da soll mal noch einer sagen auf OC könne man keine Caches finden.
