GPX in ZIP mit futuredate - Bug oder Feature?

[moenk]

Hab mir gestern eine Suche gespeichert und das Ergebnis als GPX bestellt. Dann kamen diese Dateien:

-rw-r--r--  1 moenk  users      4595 13. Mai 00:58 ocde31071293.zip
-rw-r--r--  1 moenk  users     24021  4. Jun 2159  ocde31071293.loc
-rw-r--r--  1 moenk  users    715219  4. Jun 2159  ocde31071293.gpx

 

[Spike05de]

Hab mir gestern eine Suche gespeichert und das Ergebnis als GPX bestellt. Dann kamen diese Dateien:

-rw-r--r--  1 moenk  users      4595 13. Mai 00:58 ocde31071293.zip
-rw-r--r--  1 moenk  users     24021  4. Jun 2159  ocde31071293.loc
-rw-r--r--  1 moenk  users    715219  4. Jun 2159  ocde31071293.gpx

Vielleicht liegt das an folgendem Update: http://blog.geocaching.de/?p=234

 

[mirosch]

Das ist blöd. Da sind dann ja jede Menge Caches dabei, die es jetzt noch gar nicht gibt... ;-D

 

[Anonymous]

Hmm, da ist in der tat etwas schief:

-rw-r--r-- 1 schrottie schrottie 283651 2038-01-19 04:14 ocde25605927.gpx

Allerdings dürfte das nichts mit dem Update zu tun haben, denn das alte GPX kommt ebenfalls mit falschem Datum an, und da wurde ja nichts weiter geändert. Der Fehler ist also offenbar schon etwas älterer Natur. Allerdings sollte das doch eher unproblematisch sein, oder?

 

[Anonymous]

Das ist blöd. Da sind dann ja jede Menge Caches dabei, die es jetzt noch gar nicht gibt... ;-D

Das eröffnet den FTF-Geiern ganz neue Horizonte...

 

[moenk]

Ist schon etwas schlecht auseinander zu halten welches die neue PQ^h^hSuche und welches die von letzter Woche ist.

 

[Anonymous]

Ist schon etwas schlecht auseinander zu halten welches die neue PQ^h^hSuche und welches die von letzter Woche ist.

Einfach immer überschreiben...

 

[Oliver]

Hallo moenk,

an der Stelle verwenden wir eine kleine PHP-ZIP-Klasse, die Datumsangaben im ZIP nicht unterstützt. Je nach Entpacker steht dann evtl. was anderes drin. Für die XML-Schnittstelle habe ich zwischenzeitlich ein system()-Aufruf zum zip-Binary von Linux eingebaut ... das läuft auch deutlich performanter als die PHP-Variante ... weils eben Binärcode ist und vermutlich etwas optimierter als die kleine PHP-Klasse ...

Bis zur Überarbeitung der Suchfunktion (die soll vereinfacht werden), sollte man die entpackten GPX-Dateien im Auge behalten

Grüße,
Oliver

 

[moenk]

Ist auch kein größeres Problem, fiel mir nur grad so auf wo ich mit dem Kram rumspiele.

 

[DunkleAura]

an der Stelle verwenden wir eine kleine PHP-ZIP-Klasse, die Datumsangaben im ZIP nicht unterstützt. Je nach Entpacker steht dann evtl. was anderes drin. Für die XML-Schnittstelle habe ich zwischenzeitlich ein system()-Aufruf zum zip-Binary von Linux eingebaut ... das läuft auch deutlich performanter als die PHP-Variante ... weils eben Binärcode ist und vermutlich etwas optimierter als die kleine PHP-Klasse ...

bevor ich es vergesse (ist keine kritik reine information) seit PHP 5.2.0 hat php seien eigene zip klasse mit.
die methode ZipArchive::addFromString sollte IMHO das leisten was ihr braucht.

ob es performanter ist als ein exec aufruf weiss ich nicht direkt aber es wäre eine externe bibliothek weniger.

 

[Oliver]

bevor ich es vergesse (ist keine kritik reine information) seit PHP 5.2.0 hat php seien eigene zip klasse mit.
die methode ZipArchive::addFromString sollte IMHO das leisten was ihr braucht.

ob es performanter ist als ein exec aufruf weiss ich nicht direkt aber es wäre eine externe bibliothek weniger.

Danke für den Tipp, hört sich schonmal interessant an ... die bisherige PHP-Klasse hat den Vorteil, dass alles im Speicher abläuft (bei großen Archiven wieder ein Nachteil) ... die exec-Variante hat den Nachteil, dass erst die Datei auf der Festplatte angelegt werden muss, dann gezippt und wird dann in einem 2. HTTP-Request ausgeliefert ... schön, dass PHP hier nun auch was bietet (OC hat ja (etwa) mit PHP 4.2 angefangen ... da war noch manches anders )