Depuis quelques temps déjà j'observe que l'espace disponible sur le disque dur de mon serveur diminue et diminue... Normal ? Oui mais... pas à ce point.

Je me décide à aller enquêter, la première étape étant de trouver le coupable (si il y a un), je me lance. À grand coup de du -hcs * en partant de la racine je remonte petit à petit vers ce qui occupe le plus de place sur le disque.

Sans surprise, j'arrive jusqu'au dossier /var/mail... qui contient toutes les boites emails du serveur (non c'est vrai ?).
Normal en même que ce dossier soit énorme mais les boites on des tailles énormes surtout certaines qui me font grincer des dents : 486 Mo pour une centaine de mails c'est beaucoup trop !

Alors je vais bien évident voir ce qui occupe toute cette place et à ma grande surprise je découvre que tous les mails supprimés... ne sont pas supprimés ! Les emails marqués pour suppression (en imap) sont très facile à identifier puisqu'il sont marqué d'un T à la fin du nom du fichier.

Alors pourquoi les emails supprimés ne le sont plus ? Il l'était bien avant. Un petit check de ma configuration de courier-imap s'impose.
Tout d'abord les emails marqués comme supprimés doivent aller dans la corbeille IMAP_MOVE_EXPUNGE_TO_TRASH=1 ça c'est ok.
 Ensuite la purge de la corbeille : IMAP_EMPTYTRASH=Trash:7 c'est ok aussi.

Alors pourquoi le bouzin bouzine pas bien ? Dans le fichier de configuraton de courier-imap on lit bien que pour purger la corbeille, la date CTIME des emails est vérifié plutôt que la date ATIME. Soit, allons de ce pas vérifier la date de ces emails supprimés qui jouent aux revenants. Un petit ls -l --time=ctime ou ls -lc m'indique très rapidement que tous les fichiers du répertoire (en l'occurrence .Trash/cur/) ont la même date CTIME et cette date c'est aujourd'hui... plus précisément très tôt ce matin.

Comment ce fait-ce ? Je googelise à propos de courier-imap - que j'estime coupable à ce moment là - sans rien trouver de génial dans les mailings-list à part que pas mal d'autre courrier-imapeur qui se plaignent du même problème et pas vraiment de solution visiblement sauf pour ceux qui utiliseai rsync qui modifierai la date CTIME des fichier rsyncé.




Alors moi je ne pratique pas le rsync sur mon dossier mail puisque je backup via FTP je tar. La cause rsync est donc exclue... Mais si c'était tar ? Puisque Rsync créer bien le problème pourquoi pas un simple tar. En même temps ça se saurait, et puis pas possible j'ai mis tous les --preserve-truc qui était existant dans le man - tu sais genre mode parano-bourrin.




Dans le doute je test quand même ma commande de backup... Et paf ! Oh surprise qu'elle ne fut pas, un tar modifie la date de modification des fichier tarés marquer pour suppression qui ne sont pas supprimés (vous suivez ?) Je googlize pour trouver pourquoi tar modifie la date CTIME et rien de rien. Je fouille dans le man de tar pour trouver un --preverve-ctime ou option du genre que je n'aurais pas vu... Et c'est le néant.




Alors je me dit que c'est quand même mal fichu, qui va falloir que je trouve une autre solution de backup ou faire un cp avant qui lui préserve la date ctime et puis que c'est quand même bizarre que tar modifie le CTIME du fichier taré et que ça ne soit pas plus connu que ça visiblement.
Alors je test encore tar mais avec un tar -czf tout simple sans option au lieu de ma commande de backup qui ressemble plus à tar -–cz -preserve -–atime-preserve -–exclude..... -f ..... et quel fut mon bonheur de voir que là, avec un tar tout simple,  la date de mofication des fichiers (CTIME) n'était pas modifiée.
Conclusion simple et rapide : J'ai une option dans mon tar qui ne preserve pas la date de modification et ironie du sort c'est l'option --atime_preserve qui est coupable. En tentant de préserver la date ATIME, tar modifie la date CTIME. sans l'option --atime-preserve c'est l'inverse et si vous voulez préserver les deux... bien je m'en moque parce que la moi je veux que juste que le CTIME soit préservé l'option --atime-time était mise que parce que ça faisait pro de la mettre et que j'avais envie.




Conclusion : Supprimer le --atime-preserve - vos emails (en imap) seront bien purgés et vous économiserez quelques gigas octets qui vous seront sûrement bien utile.




Moralité : Less is more* !!




*ou less is better, je ne sait pas laquelle est l'originale.




EDIT : IMAP_MOVE_EXPUNGE_TO_TRASH=1 Ne déplace pas dans la corbeille les messages marqués comme supprimés mais déplace dans la corbeillle les messages réellements supprimés (purgés).