Merci Jean-Claude

pour ce mail très détaillé et aussi pour m'avoir un peu démystifier le fonctionnement de TB et du protocole IMAP.
Dans les paramètres de ton compte IMAP, as-tu demandé de "nettoyer le dossier courrier entrant en quittant" ? Cela équivaut à un compactage.
C'est expliqué ici
http://kb.mozillazine.org/Deleting_mess ... P_accounts
Non la case n'est pas cochée, ni vider la corbeille d'ailleurs
Par contre, tu pourrais utiliser la recherche globale, pour vérifier si tes mails disparus sont dans d'autres dossiers. Pour utiliser la recherche globale, voir
https://support.mozilla.org/fr/kb/recherche-globale. Il te faudra malheureusement te souvenir du contenu significatif de certains de ces mails pour lancer une recherche.
C'est la première chose que j'ai testé depuis l'outil de recherche de TB en scannant chaque dossier/sous-dossier de chaque compte mail.
[edit]Je viens de me rendre compte d'une erreur en me relisant. Non, je n'avais pas fait de recherche globale. J'ai juste utilisé le filtre rapide (que je trouve plus pratique et ergonomique) dans tous les dossiers[/edit]
J'ai fait la même chose en recherchant un contenu de fichier par l'OS depuis un terminal sous Linux (copier tel quel, adapter <adresse_mail_connue> et <profil_tb>, copier à nouveau, coller dans un terminal et exécuter) :
Code : Tout sélectionner
grep -ir <adresse_mail_connue> <profil_tb> |awk -F: '{ print $1 }' |sort -u
Cette commande liste tous les fichiers qui contiennent une adresse mail connue.
Pour mon cas, je n'ai rien vu d'anormal (genre un déplacement non désiré) ; tout semble à sa place...
Concernant la base de données de la recherche globale, elle ne sert qu'à la recherche globale, et ne permet pas de reconstituer les messages. Elle ne contient que les index des mails, et une portion limitée de leur texte lisible, utiles à la recherche.
Par contre, tu pourrais utiliser la recherche globale, pour vérifier si tes mails disparus sont dans d'autres dossiers. Pour utiliser la recherche globale, voir
https://support.mozilla.org/fr/kb/recherche-globale. Il te faudra malheureusement te souvenir du contenu significatif de certains de ces mails pour lancer une recherche
Un truc de fou

! En cherchant par son adresse mail, un mail disparu qu'un copain m'a envoyé, je vois effectivement des portions de ce mail en clair mais quand je tente de l'ouvrir, il n'apparait pas dans la discussion. J'ai tenté une autre recherche "Gloda" sur plusieurs mots contenus dans ce mail. Il m'a affiché une autre portion du texte du même mail...
J'en conclue qu'il doit bien être quelque part en entier, non ?
=> ah l'espoir renaît
Concernant la fonction de réparation.
Sauf erreur de ma part, elle répare l'index à partir du contenu du fichier mails. Cela revient à supprimer le fichier index .msf dans le profil qui sera reconstitué automatiquement au redémarrage de Thunderbird.
Mais je n'ai trouvé aucune description détaillée sur cette fonction sur le site de Mozillazine, qui est une référence
Donc rien à craindre ici à priori, d'après ce que tu dis...
- dans Thunderbird, il est possible de garder une copie des mails au complet sur le PC, en activant l'option dans les paramètres des comptes, à la rubrique " synchronisation et espace disque". Cela grossit l'espace disque occupé et n'a d'intérêt que pour la consultation des mails en étant hors ligne. Cela n'affecte pas la synchronisation IMAP.
- "réparer le dossier" en IMAP n'e devrait avoir de sens que si tu conserves les mails sur ton PC, pour une consultation hors ligne, puisque cette fonction de réparation vise le fichier index, en se basant sur le fichier des mails.
Donc, si je comprends bien, une fois les mails téléchargés ils sont en complet dans d'autres fichiers que INBOX et cie. Si il y a un problème IMAP ou une opération côté serveur (genre un admin qui supprime des mails par erreur) ça ne se répercutera pas sur les mails déjà téléchargés. C'est bien ça ?
En effet dans l'absolu, je souhaiterais pouvoir consulter hors ligne (en cas de panne réseau par exemple), même si ça m'oblige à mettre en place une gestion "interne" pour alléger l'espace disque occupé.
Là je m'interroge moi-même sur le conflit possible entre la synchronisation IMAP qui rafraîchit l'index à partir des mails sur le serveur, et la fonction "réparer le dossier" qui "devrait" réparer l'index à partir du fichier des mails local.
Tu veux dire que la panne pourrait venir de la réparation, c'est ça ? Dans ce cas, comment l'éviter une prochaine fois ?
Une cause possible de tes problèmes, serait que ce fichier des mails local est lui-même corrompu.
Une solution, à tester, serait de décocher l'option "conserver les messages de tous les dossiers de ce compte sur cet ordinateur". Ensuite fermer Thunderbird et supprimer manuellement avec l'explorateur des fichiers, les fichiers inbox et inbox.msf dans le répertoire ImapMail concerné.
Redémarre ensuite Thunderbird. Le fichier des mails, inbox, ne sera recréé à neuf que si tu réactives l'option de conserver les mails sur le PC ( mais ce n'est pas une option nécessaire); et le fichier index, inbox.msf, sera recréé automatiquement par la synchronisation IMAP.
Refais ensuite tes tests de "réparation" pour vérifier si ton dossier est de nouveau OK.
J'ai testé, malheureusement ça ne donne rien de plus et j'ai perdu les mails qui étaient dans INBOX puisque tu m'as demandé de supprimer inbox et inbox.msf. Fort heureusement j'ai une copie de sauvegarde et pour être franc, je ne supprime jamais, je renomme
Aussi avant de décocher "conserver les messages de tous les dossiers de ce compte sur cet ordinateur" dans le menu "Synchronisation et espace disque" j'ai remarqué depuis "Avancé..." que rien n'était coché pour le compte où j'ai perdu des mails (après avoir fait ce que tu proposes, tous les dossiers sont cochés). Je ne sais pas si cette information est utile...
Sinon ... je viens de faire une découverte sympatoche
Tes explications m'ont bien inspiré ... j'ai eu une intuition.
Maintenant que j'ai des bribes de mails, j'ai tenté de rechercher ces bribes dans les fichiers directement depuis l'OS.
Si je fais (copier tel quel, adapter <bribe_texte_connue> et <profil_tb>, copier à nouveau, coller dans un terminal et exécuter) :
Code : Tout sélectionner
grep -ir <bribe_texte_connue> <profil_tb> |awk -F: '{ print $1 }' |sort -u
=> ça me sort UN SEUL fichier : global-messages-db.sqlite
Donc le mail complet serait dedans ah ah
Je savais déjà que FF et TB utilisaient le SGBD léger Sqlite mais je n'ai jamais creusé pour voir le contenu ou son organisation.
Si je fais (copier tel quel, adapter <bribe_texte_connue> et <profil_tb>, copier à nouveau, coller dans un terminal et exécuter) :
Code : Tout sélectionner
bribe="<bribe_texte_connue>" ; sqlite3 "<profil_tb>/global-messages-db.sqlite" .dump \
|awk 'BEGIN { RS = ");\n" ; ORS = ");\n"
} /^INSERT INTO "messagesText_content" VALUES\(.+$/ && /'"$bribe"'/ { print ">" $0 }'
=> je retrouve bien le mail complet

(explications en [1])
=> on peut toujours récupérer ses mails, par contre il faut que je trouve s'il y a une solution pour savoir dans quel dossier ils sont rattachés, auquel cas je saurais quels mails ont été supprimés de TB.
La suite
Si je fais (copier tel quel, adapter <profil_tb>, copier à nouveau, coller dans un terminal et exécuter) :
Code : Tout sélectionner
sqlite3 <profil_tb>/global-messages-db.sqlite 'SELECT folderURI FROM folderLocations
WHERE folderURI LIKE "imap://%" GROUP BY folderURI ORDER BY folderURI'
=> donne la liste des dossiers IMAP que TB gère (explications en [2]
Si je fais (copier tel quel, adapter oldest_date, <mail_expediteur>, <dossier_imap> listé avant et <profil_tb>, copier à nouveau, coller dans un terminal et exécuter) :
Code : Tout sélectionner
oldest_date="2020-08-01" ; mail="<mail_expediteur>" ; imap_folder="<dossier_imap>" ; \
sqlite3 <profil_tb>/global-messages-db.sqlite \
'SELECT DATETIME( SUBSTR( m.date, 1, 10 ), "unixepoch", "localtime" ) AS dt, fl.name, mtc.c1subject, mtc.c0body
FROM messagesText_content AS mtc INNER JOIN messages AS m ON mtc.docid = m.id
AND ( m.date >= STRFTIME( "%s", "'$oldest_date' 00:00:00" ) * 1000000 ) AND mtc.c4recipients LIKE "%'$mail'"
INNER JOIN folderLocations AS fl ON fl.folderURI = "'$imap_folder'"'
=> je récupère tous les mails reçus depuis le 01/08/2020 => tout est OK, comme je suis trop content

(explications en [3])
=> au final je peux accéder au contenu des mails (je n'ai pas essayé les PJs) mais je n'arrive pas à réparer TB pour autant...
J'ai passé presque une journée sur le problème (j'en ai même oublié de manger

) mais je trouve que ça valait le coup.
Le problème est partiellement résolu !
------
[1]
Explications :
bribe définit le texte à rechercher (pour
raison de compatibilité, ne mettre que les caractères alpha-numérique),
sqlite ...
.dump (ne pas oublier le "." devant dump)
extrait au format SQL la base de données en clair et lisible,
awk ...
RS = ...
ORS = ... redéfinit les
séparateurs d'enregistrements en entrée et en sortie car les INSERT peuvent être sur plusieurs lignes et se terminent par ");" avant un saut de ligne "\n",
/^INSERT ..../ si la ligne concerne un "INSERT" dans la table "messagesText_content" ET qu'il contient la bribe recherchée ALORS on affiche l'enregistrement (avec le contenu du mail) tel qu'il est stocké dans la base de données.
[2]
SELECT folderURI FROM folderLocations affiche les dossiers,
WHERE ... LIKE "imap ... ne conserve que les dossiers IMAP,
GROUP BY ...
ORDER BY ... on élimine les doublons (je n'ai pas compris pourquoi il y en avait) et on trie par ordre alphabétique
[3]
Explications (désolé c'est long) :
oldest_date est la date de consigne depuis laquelle on cherche les mails au format (AAAA-MM-JJ année-mois-jour),
<mail_expediteur< est l'adresse mail de l'expéditeur (la notre quoi),
<dossier_imap> est le dossier dans lequel chercher (donné par la commande précédente ; il faut copier tel quel),
SELECT ... est la requête qui permet de retrouver les mails,
DATETIME( SUBSTR ...
AS dt est la commande qui convertit la date des mails au
format Unix timestamp dans un format compréhensible par nous

, c'est la date de réception du mail (nota : on multiplie par 1.000.000 car ...
je n'ai pas compris la raison),
fl.name, mtc.c1subject, mtc.c0body affichent pour chaque mail le dossier IMAP, le sujet et le contenu,
FROM messagesText_content AS mtc INNER JOIN ...
messages AS m ...
INNER JOIN folderLocations met en relation le texte des mails, les mails et les dossiers IMAP,
ON mtc.docid = m.id ...
AND ...
AND ... indique la condition de relation entre le contenu des messages et les messages (voir après),
mtc.docid = m.id le contenu correspond au message,
( m.date >= STRFTIME( "%s", "'$oldest_date' 00:00:00" ) * 1000000 ) la date du message est postérieure à la date de consigne (voir plus haut pourquoi on multiplie par 1.000.000) en insèrant la variable $oldest_date (attention voir [4]),
mtc.c4recipients LIKE "%'$mail'" cherche les mails de l'expéditeur voulu en insérant la variable $mail (attention voir [4]),
INNER JOIN folderLocations AS fl ON fl.folderURI = "'$dossier_imap'" le dossier IMAP correspond à celui attendu en insérant la variable $dossier_imap (attention voir [4])
[4]
il y a plusieurs façon d'insérer le contenu d'une variable ; j'ai choisi celle qui consiste à insérer par l'extérieur de la commande et ça permet de l'insérer dans la commande AVANT exécution. Pour ce faire, vu que ma commande
'SELECT commence par un guillemet simple, on l'appelle généralement "QUOTE", je place aux endroits où je veux insérer, un QUOTE suivi de la variable et j'ajoute un QUOTE pour finir.
Schématiquement ici ça donne :
<QUOTE>code...<QUOTE>$variable<QUOTE>code ...<QUOTE> ainsi $variable est inséré dans le code sans complication
Nota : parfois la variable doit être contenue dans des doubles quote (ou guillemet double) appelés souvent DQUOTE
Schématiquement : <QUOTE>code...
<DQUOTE><QUOTE>$variable<QUOTE>
<DQUOTE>code ...<QUOTE>