Beiträge von generalsync

Zitat von LilaLisa81

Kannst du eine Beispieldatei in Floating Time und ohne TZID posten, die bei dir funktioniert?

Deine Datei mit hinzugefügtem BEGIN:VCALENDAR ist bei mir korrekt als Floating-Time importiert worden, der für den Benutzer sichtbare Unterschied ist die Angabe der Zeitzone "Lokale Zeit" wenn im Termin-Dialog Einstellungen|Zeitzone anzeigen aktiv ist. Natürlich ist der Termin dennoch "falsch", da er von Spontacts mit falschen Daten generiert wurde. Dementsprechend zeigt er nur dann die "korrekte" Zeit, wenn du in der richtigen Zeitzone bist

Da der Dienst ja auch den Ort zu erfassen scheint, sollte er m.E. die Zeitzone des Zielorts nehmen und gut. Ansonsten ist es auch in Ordnung, ein "Z" an die Startzeit anzuhängen und damit eine Angabe in UTC zu machen, ohne zu spezifizieren in welcher Zeitzone diese angezeigt werden soll. Derzeit scheint der Anbieter die Eingabe aus der Zeitzone des eingebenden Benutzers korrekt in UTC zu wandeln, die Zeitzoneninformation anschließend zu verwerfen und das Ergebnis als Floating-Time wieder auszugeben. Damit ergibt sich ein Floating-Time-Termin zu der Uhrzeit, zu der der Termin in Greenwich stattfinden würde.

Zitat von LilaLisa81

Da ist ja das manuelle Verschieben des falschen Eintrags zigmal schneller.

Wenn du manuell verschieben willst, solltest du auf jeden Fall auch die Zeitzone ändern, sonst werden die Termine automatisch "falsch" verschoben, wenn du die Zeitzone wechselst.

Für deinen Fall vermutlich bequemer: hänge an die Werte von DTSTART und ggf. DTEND (falls vorhanden) einfach ein "Z" an. Bessere Texteditoren können das per Suchen/Ersetzen. Dann sind die Termine nicht mehr Floating-Time und sollte "wie gewollt" importiert werden (19:30 passt, denke ich?). Da keine Zeitzone angegeben ist, wird Thunderbird beim Bearbeiten jedoch UTC/GMT als Zeitzone anzeigen – und die entsprechend "verschobenen" Zeiten.

Die übrigen iCal-Schlüsselwörter auf die du dich beziehst sind nur für komplexere Termine relevant, z.B. bei Terminen, die sich wiederholen.

Zitat von LilaLisa81

geht er davon aus, dass sie in UTC ist und verschiebt sie um eine oder zwei Stunden nach hinten.

Abgesehen vom fehlenden BEGIN:VCALENDAR (kopierfehler?) fällt an deinem Termin auf, dass die Zeit in sogenannter Floating-Time angegeben ist. Floating Time (im deutschen Thunderbird "Lokale Zeit") ist keine Zeitzone und nicht identisch mit UTC. In meinen Tests hat der Import dahingehend jedoch funktioniert.

Floating-Time-Termine finden in allen Zeitzonen zur selben Uhrzeit, aber zu ggf. unterschiedlichen Zeitpunkten statt (z.B. beginnt und endet ein ganztägiger Termin immer um 0 Uhr und ist entsprechend in Floating-Time). Aus dem Kontext würde ich jedoch vermuten, dass der Termin eigentlich eine Zeitzone haben sollte und damit inhaltlich falsch ist. Google unterstützt kein Floating-Time (außer bei ganztägigen Terminen), daher ist es wenig verwunderlich, dass die Zeit dort falsch (bzw. "fälschlicherweise richtig") interpretiert wird.

Zitat von SusiTux

Wenn Du (oder jemand anderes) jetzt noch eine App kennst/kennt, dann wären wir fast am Ziel.

Ich dachte, DavDroid könnte das. So gibt es entsprechend aussehende Klassen im Quellcode. Ob diese genutzt werden, weiß ich nicht, aber ich bin bisher davon ausgegangen. Ich hatte irgendwie im Kopf, wir hätten das "wie" hier schon geklärt und es geht nur noch um das "warum" einer separaten Dav-App.

[OT]

Zitat von SusiTux

In allen Modellen zu Softwareschichten, die ich kenne, ist die Datenbank die unterste Schicht

In Netzwerkschichten ist die Anwendung oben (und die Datenbank ist hier die direkte Schnittstelle zu den Apps). Wenn ich nochmal drüber nachdenke ist die Netzwerksicht für diese Diskussion tatsächlich nur bedingt passend, ist nur eben die Richtung aus der ich entwickle.

Zitat von SusiTux

Die Hochspannung dient ja nur dem Transport und ist nicht für den End-Verbraucher gedacht.

Genau: vCard / CardDav ist nur für den Transport gedacht, und nicht für die interne Verwendung in Anwendungen. Darum ging es mir in meiner (vielleicht verunglückten) Anpassung deiner Analogie. Natürlich wäre es aus Nutzersicht schön, wenn eine Windows-Anwendung auch unter Android liefe (also auch die "Spannungen für Endverbraucher" normiert wären), aber das ist wenig realistisch, schon allein wegen der unterschiedlichen Anforderungen der Geräteklassen und Nutzergruppen.

Wird der Transport-Standard getauscht (z.B. Google-proprietär gegen GeneralSync) funktionieren Apps weiter ("keine neuen Geräte kaufen"). Wird das Betriebssystem gewechselt ("in Land mit anderer Spannung ziehen"), braucht man neue Apps ("Geräte neu kaufen"), kann aber den Transport (und damit die Daten) weiter benutzen ("es gibt immer noch Strom"). Gerade im letzteren Fall hinkt die Analogie natürlich gewaltig, aber ich hoffe der Punkt wird klarer?

[/OT]

Zitat von SusiTux

Ja, aber das ist mindestens eine Schicht unterhalb des Protokolls und noch weiter unterhalb des Austauschformates.

Ich glaube, wir reden gerade aneinander vorbei: von Android wird nur die oberste Schicht vorgegeben (Datenbank), die von den Kontakt- und Kalender-Apps genutzt werden. Alle Schichten darunter sind Aufgabe von Apps mit sogenannten Synchronisationsadaptern. Die Synchronisationsadapter können dann beliebige Dinge tun, i.d.R. also in ein Austauschformat wandeln und ein Netzwerkprotokoll bedienen.

Diese Normierung der obersten Schicht ermöglicht es, dass Kalender- und Kontakte-Apps nicht nur mit explizit vom Entwickler unterstützten Lösungen funktionieren, sondern mit allen Synchronisationsprovidern. Wenn Apps das wollen, können sie auch alle Schichten selbst implementieren und sind völlig frei (so z.B. bei mindestens einem Exchange-Client für Android) – können Daten aber nur mit Apps austauschen, die speziell für diesen Datentyp entwickelt wurden.

Zitat von SusiTux

Um bei dem Beispiel mit der elektrischen Spannung zu bleiben. Man stelle sich mal vor, Niedersachsen würde ein 240V Spannungsnetz haben und Bayern auf 50V Gleichstrom bestehen. Klar, mit den entsprechenden "Apps", also Wechselrichter usw., könnte man das schon hinbekommen. Aber das wäre doch ein Albtraum.

Es ist schwer, in deinem Beispiel zu bleiben. Wenn ich es versuchen muss: die Norm ist Hochspannung, und Europa und die USA nutzen in Privathaushalten 240V / 120V mit unterschiedlichen Steckern. Die Stromanbieter müssen für die korrekte Spannung sorgen, die Endkunden können nur Geräte für Ihr Betriebssystem Land nutzen. Letzteres war schon immer so, und stört niemanden.
Natürlich kann man argumentieren, dass Hochspannung mit einheitlichen Steckern einheitlicher und offener ist, aber sie ist gleichzeitig in Privathaushalten unglaublich unpraktisch. Und ein reines 240V/120V-Netz wäre unglaublich ineffizient. Daher macht es Sinn, beides zu haben. Und da beide Steckertypen/Spannungen für Privathaushalte verschiedene Vor- und Nachteile haben (und natürlich auch, da sich die Stecker/Spannungen historisch entwickelt haben und am Markt etabliert sind!), bleiben auch die unterschiedlichen Normen für Privathaushalte erhalten.

Zitat von SusiTux

Können die Apps, die es zum CardDav-Austausch gibt, KIND und MEMBER nutzen und damit die Gruppen als Listen ins Cardbook bringen, oder wird das schon seitens Google blockiert?

Eine CardDav-App kann eine Gruppen-vCard als "Gruppe" in die Android-Datenbank einfügen und ihre MEMBER entsprechend verknüpfen. Ob und wie sie das tut, ist dem Entwickler überlassen. Google blockiert hier nichts. Problematisch wird es nur, wenn die von Google vorgegebene oberste Schicht eine Information nicht abbilden kann (z.B. kennt Android keine Unterscheidung zwischen einer ausschließlich privaten Mobilfunknummer und einer Mobilfunknummer, die die weder eindeutig privat noch eindeutig geschäftlich ist). Hier muss dann im Einzelfall eine sinnvolle Entscheidung getroffen werden.

Alternativ kann eine Kontakte-App einen eigenen CardDav-Stack aufbauen und ein eigenes Datenformat nutzen. Andere Apps haben dann jedoch nur Zugriff, wenn sie dieses "eigene" Datenformat kennen UND entsprechende Berechtigungen haben UND die Kontakte-App diesen Zugriff aktiv ermöglicht. Daher wird dieser Weg fast ausschließlich für Apps verwendet, auf deren Daten keine weiteren Apps zugreifen sollen.

Zitat von FrellPumpkin

Deshalb meine Frage, gibt es eine Möglichkeit die Sortierung der Termine irgendwie per Tastatur oder Kontextmenü zu ändern?

Entsprechend der Dokumentation zu dem technischen Typ der Liste ist es zumindest nicht direkt möglich. Die dort beschriebene Empfehlung ist es, die Funktionalität zusätzlich über das Menü zugänglich zu halten. Für die Suchliste im Kalender-Tab ist mir aber kein derartiges Menü bekannt.

Als Notlösung / Anregung für ein Add-on: in der Fehlerkonsole folgendes evaluieren, um einen Klick auf die erste Spalte auszulösen:

var tree = Components.classes["@mozilla.org/appshell/window-mediator;1"].getService(Components.interfaces.nsIWindowMediator).getEnumerator("mail:3pane").getNext().document.getElementById("unifinder-search-results-tree");tree.view.cycleHeader(tree.columns[0])

Die 0 in eckigen Klammern ist die Spalte (0 = erste Spalte, 1 = zweite Spalte), alternativ kann sie auch durch einen Spaltennamen in Anführungsstrichen ersetzt werden (z.B. "unifinder-search-results-tree-col-title" oder "unifinder-search-results-tree-col-startdate"). Definitiv nicht schön, aber ich habe zu lange nicht mehr mit XUL-Trees gearbeitet um eine saubere Lösung parat zu haben.

Zitat von SusiTux

Aus Sicht des Anwenders sind die Datenbank und dessen Format daher sekundär. Von denen sollte ich gar nichts spüren.

Genau deshalb mein jein. Nein, da es eine Datenbank ist. Auch bei Apple und Microsoft ist das interne Format nicht vCard, sondern eine Datenbank. An dieser Stelle ist ein eigener Kosmos nichts schlechtes, solange er ausreichend mächtig, dokumentiert und für jeden (Entwickler) nutzbar ist.

Für den Anwender interessieren diese internen Schnittstellen nicht. Konzeptionell kann unter Android jede App mit den entsprechenden Berechtigungen auf die Datenbank greifen. Ob durch die App nun Google-, vCard- oder GeneralSync-Kontakte laufen ist damit egal. Im Ergebnis kann ich mich als Nutzer darauf verlassen, meine Kontakte-App sowohl mit Google, einer CardDav-App als auch GeneralSync nutzen zu können, sofern sich die App an die Dokumentation des internen Kosmos hält. Das ist der Punkt, an dem ich Google kritisieren würde: Funktionen die in Google und Exchange fehlen sind in den Standard-Apps zum Teil bewusst gesperrt, obwohl sie in der internen Datenbank für Entwickler nutzbar sind.

Welche Datenbank-bereitstellenden Apps nun vom Hersteller beigelegt werden, variiert. Google stellt z.B. nur Exchange- und Google-Adapter bereit, eine CardDav-Lösung fehlt. Solange eine solche Lösung aber technisch implementiert werden kann und legal vertrieben werden darf, finde ich das akzeptabel. Entsprechend gibt es CardDav-Adapter für Android, die diese Brücke schlagen. Schlimm wäre es hingegen, wenn solche Adapter nicht entwickelt werden könnten oder deren Vertrieb über den Play Store oder andere Kanäle eingeschränkt werden würde. Gerade Apple macht da m.E. eine deutlich schlechtere Figur als Google (aufgrund der Einschränkung von Vertriebswegen).

Zitat von SusiTux

Lass mich raten: Das Ganze hat, im Gegensatz zu vCard, ein android-proprietäres Format.

Jein. Letztendlich ist es ja ein Implementierungsdetail, wie die Daten intern repräsentiert werden. vCard ist ja kein geeigneter Standard für eine Datenbank, sondern ein Standard für ein Austauschformat.

Die Kontakte-Datenbank von Android ist für Android-Verhältnisse erstaunlich angenehm umgesetzt, wird allerdings selbst von den Standard-Apps nicht vollständig unterstützt (so deaktiviert die Standard-Kontakte-App z.B. alle Bearbeitungsfunktionen, wenn man in der Deklaration von editierbaren Bestandteilen zu stark von der Funktionalität von Exchange oder Google abweicht). Dort sehe ich viel eher das Problem als in einem fehlenden nativen Austauschformat; letzteres lässt sich ja trivial nachrüsten.

Man könnte ja auch über Lightning lästern, dass es eine proprietäres Datenbankformat nutzt, und nur beim Im-/Export und dem Austausch mit CalDav-Servern in iCal wandelt.

Ich bin gerade zufällig mal wieder über den Lexikon-Artikel zur Smartphone-Synchronisierung gestoßen. Was daran auffällt: die Pro/Conra-Boxen, die früher mittels [pclist]-Tag eingebaut werden konnten, scheinen von der neuen Forensoftware nicht angenommen zu werden. Dementsprechend sind im Artikel unschöne Tags sichtbar, die für Normalmenschen wohl eher weniger hilfreich sind – ich vermute das betrifft auch weitere Artikel.

Zitat von SusiTux

Android unterstützt meines Wissens von Haus nicht einmal CardDav oder CalDav ansich sondern benötigt zusätzliche Apps.

Nur dazu vielleicht als Ergänzung: Android unterstützt zwar nicht vCard, hat aber einen echten Gruppenbegriff (man kann Kontakten also Gruppen zuordnen). Die Oberfläche dazu ist jedoch uneinheitlich, so kann z.B. die offizielle Kontakte-App erst dann Gruppen anlegen, wenn ein Adressbuch bereits Gruppen enthält.

Ein Synchronisationstool kann also Thunderbird-Mailinglisten als Android-Gruppen bereitstellen (und umgekehrt), auch wenn es in Thunderbird Beschränkungen gibt: Kontakte ohne E-Mail-Adresse oder mit einer in der Gruppe bereits existierenden E-Mail-Adresse können nicht als Mitglieder einer Mailingliste dargestellt werden. So funktioniert das zumindest mit GeneralSync, wie weit andere Tools entsprechende Funktionen für das Standard-Adressbuch bieten habe ich nicht im Kopf.

Als Ergänzung zu slengfe: Thunderbird unterstützt in Listen ausschließlich Kontakte mit E-Mail-Adresse. Darüber hinaus gibt es eine ganze Latte an Problemen, wenn zwei Kontakte in derselben Liste dieselbe E-Mail-Adresse haben. Sollten deine Add-ons also unschuldig sein, könnte es daran liegen.

Ich kenne das "Modul" nicht, und bin mir auch gerade nicht sicher, was du mit "Modul" meinst.

Thunderbird unterstützt ab Version 52 keine Add-ons mit binären Bestandteilen mehr (unter Windows: ein Add-on mit .dll). Der Entwickler des Add-ons muss eine neue Version entwickeln, die ohne nativen Code auskommt oder dafür einen unabhängigen Prozess nutzt.

Plugins (unter Windows: eine .dll, die über NPAPI direkt Funktionalität bereitstellt) wurden in Gecko für Firefox 52 deaktiviert, durch deaktivieren der about:config-Einstellung plugin.load_flash_only lässt sich das jedoch derzeit noch rückgängig machen (iirc).

Zitat von SusiTux

Näheres kann Dir vielleicht generalsync dazu sagen.

Ohne die Daten gesehen zu haben kann ich aber auch nur bedingt hellsehen, wo das Problem liegt. Eine Vermutung ins Blaue hinein wäre vielleicht ein Zeichensatz- oder Newlineproblem, wenn die Daten ansonsten in Ordnung aussehen. Denkbar wäre auch, dass GMX über nicht unterstützte Daten stolpert, z.B. Aufgaben oder Termine mit komplexen Wiederholungsregeln.

Zitat von pixel

Gibt es Dokus zum verändern der Kalender-Dateien (Nicht-ICS-Datei)?

Technisch liegen die eigentlichen Daten als sqlite-Datenbank im Profil ("./calendar-data/local.sqlite"). Neben dem offiziellen Kommandozeilentool gibt es verschiedene sqlite-Viewer, bei Bedarf einfach mal "edit sqlite" oder Ähnliches in die Suchmaschine deines geringsten Misstrauens eingeben.

Vorher solltest Du natürlich zusätzlich das gesamte Profil sichern.

Hm, der Audit selbst scheint nicht veröffentlicht geworden sein, oder habe ich etwas übersehen? Die öffentlichen Informationen sind ja eher dürftig.

Wenn es wirklich nur darum geht, dass ein bösartiges Add-on Keys auslesen kann wäre das ja nicht wirklich etwas neues. Add-ons können ja auch beliebige Anwendungen ausführen und so z.B. einen Keylogger starten und gnupg-Keys in verschlüsselter Form direkt von der Platte lesen.

Die Funktionalität von Add-ons ist an sich kein Sicherheitsproblem, solange Nutzer Add-ons mit derselben Sorgfalt installieren, die bei jeder anderen Software-Installation ebenfalls vonnöten ist. Ich persönlich sehe darin gerade die (einzige) Stärke von Firefox, entsprechend werde ich wohl nach dem Supportende für 52 ESR den Browser wechseln.

Mir klingt das gerade nach Panikmache. Übersehe ich etwas?

Zitat von slengfe

wie ich Chrome auf meinem Rechner ohne Adminrechte installieren kann

Ich habe Chrome bislang zwar nur testhalber verwendet, aber ist eine Installation ohne Adminrechte nicht sogar der Standard? Die Installation läuft unter Windows dann in das Profil. Unter Linux sollte ein entpacken im Home-Verzeichnis kein Problem sein. Von der Apple-Welt verstehe ich nichts, vielleicht kann sich dazu jemand anderes äußern.

Zitat von TmoWizard

Davon ist nichts zu bemerken, wäre aber auch ziemlicher Unfug! Add-ons wie z. B. Lightning und Enigmail hätten dann ziemliche Probleme, wie sollten das gehen?

Ich bezog mich auf R Kent James in der Mail "Caution about Thunderbird 52 and binary extensions" vom 16.11.16. Ich habe nicht geprüft, ob das wirklich so durchgezogen wurde, aber es scheint wohl dabei geblieben zu sein. Enigmail hat keine Binärkomponenten (es ruft lediglich die gpg-Binary auf, gpg läuft also in einem eigenen Prozess). Lightning hatte solche Komponenten, diese wurden jedoch durch JS ersetzt oder in den Core übernommen.

Zitat von Trierer

Da mit Android Tablett aber Google Kalender und leider kein Lightning funktioniert, möchte ich das Termin vom Lightning in Google zu sehen sind.

Nebenbemerkung: dein Problem (Kalender auch auf Tablet nutzen) lässt sich nicht nur durch Google lösen, siehe Lexikon-Artikel "Synchronisation mit einem Smartphone". Die dort aufgeführten Informationen zu Android-Smartphones gelten auch für Tablets. [Disclaimer: als Entwickler einer der dort dargestellten Lösungen bin ich natürlich befangen]

Zitat von Mapenzi

Es handelt sich aber nicht um die Zeilen mit den E-Mailadressen.

In Mork gibt es tote Daten, die einfach nur als Relikt mitgeschleppt werden (aber deren Verknüpfungen nicht notwendigerweise relevant sind). Die Werte der E-Mail-Adressfelder können also z.B. ohne die Verknüpfung zu einem Kontakt unabhängig fortbestehen und technisch nicht länger als E-Mail-Adressen identifizierbar sein. Mit etwas Glück sind auch übrige Daten weiterhin vorhanden, nur eben nicht mit einer Tabelle verknüpft. Dazu aus dem von Susanne verlinkten Dokument:

Zitat von MDN: Mork Structure

When copying an old Mork store to a freshly written new file, unused content in the old copy can be omitted. But what defines unused ? Any or root or literal not reachable from at least one table is considered unused, and can be pruned or scavenged to reduce space consumption.

Ich habe mir Mork auch nur aus der Distanz angeschaut, der Adressbuch-Code ist wohl der letzte Teil wo das noch verwendet wird. Bei Löschung eines Eintrages wird nur die Referenz zwingend entfernt, ohne die Daten selbst zu löschen.

Zum Durchquälen ist hier jedoch vor allem der Mork-Code zum Adressbuch wichtig, die zugehörigen Sourcen stehen in nsAddrDatabase.h und nsAddrDatabase.cpp. Es scheint so, als würden die 50 letztgelöschten Einträge vollständig beibehalten werden, ungeachtet der Interna von Mork (nsAddrDatabase.cpp#694, die Löschung beginnt in nsAddrDatabase.cpp#1598). Der GC läuft dann wohl nur, wenn mindestens 30% Speicherplatz freigegeben werden (nsAddrDatabase.cpp#631, man beachte auch den Kommentar "I'm not sure this calls works in Mork for all cases"). Aber wie gesagt, ich habe das nur oberflächlich betrachtet, soweit das für GeneralSync's Adressbuch-Support notwendig war.

Hi Doxner,

wurden die alten Anhänge auch unter "Extras|Gespeicherte Dateien" gelöscht? Thunderbird versucht, nicht abgeschlossene "Downloads" nach einem Neustart wiederaufzunehmen (das Speichern von Anhängen ist intern immer ein "Download", selbst bei lokal gespeicherten E-Mails).

Hi Gustav,

das Problem hatten wir hier schon mal, siehe Kalenderdaten von EssentialPIM importieren. Works nutzt einen anderen Zeichensatz als Lightning, daher muss die Datei vorher umgewandelt werden.

Edit: Das im anderen Thread beschriebene iconv gibt es auch für Windows.

Zitat von SusiTux

Das ist prinzipiell richtig, würde aber auffallen. Denn zu einer Prüfung der Integrität einer Datei gehört neben dem Hash immer auch die Dateigröße.

In der Praxis wird die Dateigröße jedoch nicht immer geprüft, beispielsweise bei Add-on-Updates für Thunderbird: die Dateigröße eines Updates wird in der update.rdf nicht abgelegt (siehe MDN-Artikel zu Add-on Updates). In der Praxis nutzen viele Anbieter hier ohnehin zusätzlich HTTPS, aber ein Update via HTTP mit SHA1-Hashes ist technisch zulässig.

Zitat von SusiTux

Zu jedem Hash-Verfahren gibt es Kollisionen.

Das ist klar, ich sprach ja auch von (starker) Kollisionsresistenz.