From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 4348E139694 for ; Wed, 31 May 2017 19:54:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6C7CDE0F19; Wed, 31 May 2017 19:54:07 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 21F93E0F06 for ; Wed, 31 May 2017 19:54:07 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dG9go-0001SD-Qy for gentoo-user-de@lists.gentoo.org; Wed, 31 May 2017 21:53:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user-de@lists.gentoo.org From: Kai Krakow Subject: [gentoo-user-de] Re: Akonadi Date: Wed, 31 May 2017 21:53:14 +0200 Message-ID: <20170531215314.4bcda242@jupiter.sol.kaishome.de> References: <1600072943.91868.1495799885176@mail.vodafone.de> <1603629.EFJFVUnfYc@sed-notebook> <20170527161338.06a313b8@jupiter.sol.kaishome.de> <2315032.M15cRLHJdE@sed-notebook> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user-de@lists.gentoo.org Reply-to: gentoo-user-de@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/WrQvaVTz_f12oFe0JGC65cU"; protocol="application/pgp-signature" X-Complaints-To: usenet@blaine.gmane.org X-Newsreader: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) X-Archives-Salt: db966f3c-232c-461f-8637-75025da7479b X-Archives-Hash: ee448f4c76e93c9c7c82397d88d6bf39 --Sig_/WrQvaVTz_f12oFe0JGC65cU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Wed, 31 May 2017 09:01:35 +0200 schrieb Sven Eden : > Am Samstag, 27. Mai 2017, 16:13:38 CEST schrieb Kai Krakow: > > Per POP3 geholte Mails sind normalerweise nicht mehr auf einem > > Server... =20 >=20 > Alles eine Frage der Einstellungen. Ich hatte, vor dem Umstieg auf > IMAP, meinen GMX-Agenen so eingestellt, das bis zu 980MB auf dem > Server verbleiben sollen. > Ich kann mich aber beim besten Willen nicht daran erinnern, was der > Standard war. Alles herunterladen, und nichts auf dem Server > belassen, oder? >=20 > > =20 > > > Aber was hilfts? Die InnoDB ist futsch... :-( =20 > >=20 > > Legt Akonadi nicht von selbst regelm=C3=A4=C3=9Fig Backups an als ZIP o= der so? > > Ich meine das mal irgendwann gesehen zu haben, finde das aktuell > > aber nicht mehr wieder. =20 >=20 > Nicht, dass ich w=C3=BCsste... >=20 > >=20 > > Aber ich finde aktuell nicht mal Akonadi in den System Settings oder > > dem Tray. Was fehlt mir? =20 >=20 > Wir User sind nicht f=C3=A4hig Akonadi per GUI zu konfigurieren, also gibt > es nur noch > A) ~/.config/akonadi/akonadiserverrc > B) ~/.config/akonadi_maildir_resource_0rc und ... > C) /usr/bin/akonadiconsole (<-- HA, doch GUI) Ganz ehrlich: Ich kann's verstehen, wirkten diese Dialoge doch eher wie Entwickler-Werkzeuge als Enduser-Dialoge. Wahrscheinlich waren Sie auch nie was anderes... Zu C) Stimmt, ich hatte die Debug-Console ein wenig vergessen, hier finden sich sogar die Einstellungsdialoge wieder... Auf dem "Agents" Reiter. > Zu B) : Hierin steht der Pfad zum Lokalen Ordner. Alle Mails darin > finden sich hier im Dateisystem wieder. >=20 > Weiterhin gibt es noch > ~/.config/akonadi_imap_resource_*rc f=C3=BCr IMAP, und sicherlich eine > Entsprechung f=C3=BCr POP3. Zumindes in den IMAP-Resourcen steht aber > leider nicht drin, wo die Mails lokal gespeichert werden. > Allerdings tippe hier ganz stark auf > ~/.local/share/akonadi/file_db_data >=20 > Letztendlich sind alle Daten bis 4096 Bytes weg, sofern sie nicht > erneut vom Server heruntergeladen werden k=C3=B6nnen, wenn man die > Datenbank l=C3=B6scht. Alles Andere ist im Dateisystem gespeichert. Ob das > nach dem L=C3=B6schen der Datenbank auch alles brav wieder indiziert wird, > wei=C3=9F ich leider nicht. Bei meinem letzten Crash wurden die alle nie wieder korrekt indiziert, die waren zwar irgendwie da aber irgendwie auch nicht. Bei einem Check wurde dann alles nach lost+found verschoben und Akonadi konnte nichts mehr damit anfangen, weil die Meta-Infos fehlen, die beim Abruf oder Sync angelegt werden. Das ist inzwischen aber Jahre her, Akonadi hat sich seitdem ver=C3=A4ndert und verbessert - ein bisschen bezweifle ich aber, dass das je wieder indiziert werden kann, da einfach die Meta-Infos aus der DB fehlen. Ich hab mal in den Code geschaut, und Akonadi scheint ziemlich essentiell darauf angewiesen zu sein und kann mit den Objekten sonst nichts anfangen und verbannt die nach lost+found. Von da aus k=C3=B6nnte ich die zwar mit etwas Script-Fu in ein Maildir verfrachten und dann wieder importieren... Sch=C3=B6n und zuverl=C3=A4ssig geht allerdings anders. Zuma= l auch jegliche Info verloren geht, in welche Ordner sich die Objekte verteilt hatten. Regelm=C3=A4=C3=9Fige Backups helfen und tun nicht wirklich weh. Wenn Speicherplatz ein teures Gut ist, kann ich Borgbackup empfehlen: Sehr schnell und extrem speichereffizient. Sichert t=C3=A4glich mein System (2TB, viele Millionen Dateien) innerhalb von 10-15 Minuten, und bereits knapp ein Jahr Backup passen auf eine 3TB Platte (ich sichere also alles und behalte es auch t=C3=A4glich, mit Ausd=C3=BCnnung nach einigen Wochen). --=20 Regards, Kai Replies to list-only preferred. --Sig_/WrQvaVTz_f12oFe0JGC65cU Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSPJIMIYCj/1CTz/WL4PtxD+QjMBQUCWS8fKgAKCRD4PtxD+QjM BecBAJ9tiKHMOD4nqe9A38MVI1b9fEcPFwCfQcYQAwC+sLOUC4XpHeOF1Qz7TvE= =x80i -----END PGP SIGNATURE----- --Sig_/WrQvaVTz_f12oFe0JGC65cU--