Questa volta, però, il mio affezionatissimo evolution sulla mia prode e customizzatissima Gentoo Linux, mi ha fatto passare qualche ora non divertentissima…

Evolution

Tutto è avvenuto nel passaggio dalla versione 2.22 alla versione 2.24 di evolution, aggiornamento che ha comportato il passaggio dal vecchio sistema di archiviazione degli indici delle mailbox all’uso di sqlite a questo scopo. Una volta riavviato evolution dopo l’aggiornamento, una finestra di popup mi avvisa che occorrerà del tempo per la conversione dei vecchi indici nel nuovo formato, operazione che, data la suddetta dimensione delle mailbox, ha preso parecchio tempo.
Alla fine dell’operazione, scopro con terrore che:

1. i filtri non sembrano funzionare, per cui alcuni messaggi nuovi vengono smistati, altri no
2. le caselle IMAP sono lentissime e che i contenuti di alcune cartelle non sono leggibili
3. i messaggi cancellati non riescono a essere eliminati dal cestino
4. lo spostamento di messaggi lascia doppioni nelle cartelle di origine e destinazione della copia

ORRORE!!!

Comincio a googolare nervosamente e scopro che parecchia gente ha il mio stesso problema.
Forte del fatto che tanto un backup lo avevo fatto prima dell’avvio della nuova versione di evolution e disperato per il fatto che avrei visto innumerevoli sorci verdi se avessi cercato di risolvere la cosa per vie più diplomatiche, ho deciso di fare la cosa più drastica: DISINTEGRARE GLI INDICI.

Prima di ciò, ho controllato in ~/.evolution/mail/local e mi sono reso conto che, accanto ai nuovi indici (estensione .ibex.index), c’erano ancora i file dei vecchi indici (estensione .ev-summary).

Quindi mi sono armato di coraggio, e ho dato i seguenti comandi:

$ evolution --force-shutdown # uccide anche tutti i demoni di evolution
$ cp -a ~/.evolution ~/.evolution_backup
$ find ~/.evolution/ -name "*.ev-summary" -print0 | xargs -0 rm -rf
$ find ~/.evolution/ -name "*.ibex.index" -print0 | xargs -0 rm -rf

Riavviato evolution, gli indici sono stati creati ex novo in una frazione di tempo rispetto alla procedura di conversione del primo avvio della nuova versione e tutto ha preso a funzionare come si deve.

Mi terrò stretti quei backup ancora per alcuni giorni, Murphy è sempre in agguato, ma alla fine di questa esperienza mi chiedo: non sarebbe meglio fare dei test di regressione un pelino più seri? Non sarebbe stato meglio fare generare gli indici da zero (visto che così ha funzionato) piuttosto che effettuare quella lunghissima e non funzionante conversione (così per lo meno notificava la finestra apposita) degli indici dal vecchio al nuovo formato?

Ciononostante, sono abbastanza soddisfatto: alla fine si è risolto tutto con due righe di bash scripting. Se si fosse trattato di software proprietario sono certo che la risoluzione del problema sarebbe stata ben più arzigogolata come minimo.

Ho scritto questo articolo nella speranza di alleviare qualche malditesta a chi si dovesse accingere a questo aggiornamento. Mi raccomando: un bel backup di ~/.evolution PRIMA di lanciare la nuova versione. Non si sa mai…

Aggiornamenti dell’ultima ora:

il problema potrebbe riproporsi con evolution 2.28.*, ed in effetti a me è successo. La sequenza di azioni da seguire con questa nuova versione è la seguente:

$ evolution --force-shutdown # uccide anche tutti i demoni di evolution
$ cp -a ~/.evolution ~/.evolution_backup
$ find ~/.evolution/ -name "*.ibex.index" -print0 | xargs -0 rm -rf
$ find ~/.evolution/ -name "folders.db" -print0 | xargs -0 rm -rf
$ evolution --offline

Riavviato evolution e ricostruiti gli indici, si può passare a lavorare in rete e il problema si spera non si ripresenti per il più a lungo il possibile…