Tous les soirs, un backup automatique des données est effectué sur
notre serveur (Windows NT). Parmi ces données, quelques boîtes aux
lettres Thunderbird (1 à 2 Go environ).
Histoire d'économiser un peu d'espace (surtout que le tout arrive sur
ZIP et DVD-R), j'aimerais un utilitaire en ligne de commande capable
de compacter ces BAL (l'équivalent de ce que fait le menu "File ->
Compact folders" dans Thunderbird).
On Fri, 09 Jul 2004 15:04:38 +0200, FantasioMagazine :
Le truc le plus dur, c'est la séparation des messages j'ai l'impression qu'il y a 2 retour ligne puis une ligne commence par "From -"
<http://annys.eines.info/cgi-bin/man/man2html?mbox+5> : An mbox is a text file containing an arbitrary number of e-mail messages. Each message consists of a postmark, followed by an e-mail message formatted according to RFC 822. The file format is line-oriented. Lines are sepa- rated by line feed characters (ASCII 10).
J'imagine que cette spécification impose implicitement que le "From " soit en début de ligne (i.e. précédé par 'ASCII 10'). Néanmoins, rien dans la RFC 822 ne semble indiquer qu'un message doit se terminer par une ligne blanche.
Le document précédemment cité dit aussi : In order to avoid mis-interpretation of lines in message bodies which begin with the four characters "From", fol- lowed by a space character, the character ">" is commonly prepended in front of such lines.
(Traduction rapide : on rajoute ">" devant les "From " qui ne représentent pas un début de message)
Néanmoins, Thunderbird ne le fait pas systématiquement, notamment quand la ligne précédente n'est pas vide.
Donc, en gros, tout ça me paraît assez flou. Je ne pense pas pouvoir me servir d'une telle spécification pour compacter moi-même les BAL, néanmoins, dans le cadre d'un backup incrémental, ça doit pouvoir suffire.
D'après <http://www.eyrich-net.org/mozilla/X-Mozilla-Status.html?en>, c'est bien le 4è bit du champ "X-Mozilla-Status" qui indique si le message a été supprimé.
Voici donc ce que je compte faire :
Lors du backup complet sur DVD-R, je sauvegarde tous les messages non supprimés, tout en gardant la liste des hashs MD5 des messages effectivement sauvegardés. Lors du backup incrémental sur ZIP-750, j'enregistre les messages non supprimés, tout en remplaçant chaque "ancien" message (i.e. déjà sauvegardé sur DVD) par son hash MD5.
En théorie, cette méthode ne garantit pas une fiabilité à 100 %, mais la fiabilité est néanmoins très bonne, d'autant que le backup sur DVD+ZIP ne sert qu'en cas de destruction simultanée des deux disques durs du serveur.
Voilà voilà, promis, dès que j'ai moins de 18 mois de retard sur mon planning des choses à faire pour avant-hier dernier délai, je m'y mets ;-)
-- schtroumpf schtroumpf Jean-Emile de France
On Fri, 09 Jul 2004 15:04:38 +0200, FantasioMagazine
<pasdespam@bill.net>:
Le truc le plus dur, c'est la séparation des messages
j'ai l'impression qu'il y a 2 retour ligne
puis une ligne commence par "From -"
<http://annys.eines.info/cgi-bin/man/man2html?mbox+5> :
An mbox is a text file containing an arbitrary number of
e-mail messages. Each message consists of a postmark,
followed by an e-mail message formatted according to RFC
822. The file format is line-oriented. Lines are sepa-
rated by line feed characters (ASCII 10).
J'imagine que cette spécification impose implicitement que le "From "
soit en début de ligne (i.e. précédé par 'ASCII 10').
Néanmoins, rien dans la RFC 822 ne semble indiquer qu'un message doit
se terminer par une ligne blanche.
Le document précédemment cité dit aussi :
In order to avoid mis-interpretation of lines in message
bodies which begin with the four characters "From", fol-
lowed by a space character, the character ">" is commonly
prepended in front of such lines.
(Traduction rapide : on rajoute ">" devant les "From " qui ne
représentent pas un début de message)
Néanmoins, Thunderbird ne le fait pas systématiquement, notamment
quand la ligne précédente n'est pas vide.
Donc, en gros, tout ça me paraît assez flou. Je ne pense pas pouvoir
me servir d'une telle spécification pour compacter moi-même les BAL,
néanmoins, dans le cadre d'un backup incrémental, ça doit pouvoir
suffire.
D'après <http://www.eyrich-net.org/mozilla/X-Mozilla-Status.html?en>,
c'est bien le 4è bit du champ "X-Mozilla-Status" qui indique si le
message a été supprimé.
Voici donc ce que je compte faire :
Lors du backup complet sur DVD-R, je sauvegarde tous les messages non
supprimés, tout en gardant la liste des hashs MD5 des messages
effectivement sauvegardés.
Lors du backup incrémental sur ZIP-750, j'enregistre les messages non
supprimés, tout en remplaçant chaque "ancien" message (i.e. déjà
sauvegardé sur DVD) par son hash MD5.
En théorie, cette méthode ne garantit pas une fiabilité à 100 %, mais
la fiabilité est néanmoins très bonne, d'autant que le backup sur
DVD+ZIP ne sert qu'en cas de destruction simultanée des deux disques
durs du serveur.
Voilà voilà, promis, dès que j'ai moins de 18 mois de retard sur mon
planning des choses à faire pour avant-hier dernier délai, je m'y mets
;-)
On Fri, 09 Jul 2004 15:04:38 +0200, FantasioMagazine :
Le truc le plus dur, c'est la séparation des messages j'ai l'impression qu'il y a 2 retour ligne puis une ligne commence par "From -"
<http://annys.eines.info/cgi-bin/man/man2html?mbox+5> : An mbox is a text file containing an arbitrary number of e-mail messages. Each message consists of a postmark, followed by an e-mail message formatted according to RFC 822. The file format is line-oriented. Lines are sepa- rated by line feed characters (ASCII 10).
J'imagine que cette spécification impose implicitement que le "From " soit en début de ligne (i.e. précédé par 'ASCII 10'). Néanmoins, rien dans la RFC 822 ne semble indiquer qu'un message doit se terminer par une ligne blanche.
Le document précédemment cité dit aussi : In order to avoid mis-interpretation of lines in message bodies which begin with the four characters "From", fol- lowed by a space character, the character ">" is commonly prepended in front of such lines.
(Traduction rapide : on rajoute ">" devant les "From " qui ne représentent pas un début de message)
Néanmoins, Thunderbird ne le fait pas systématiquement, notamment quand la ligne précédente n'est pas vide.
Donc, en gros, tout ça me paraît assez flou. Je ne pense pas pouvoir me servir d'une telle spécification pour compacter moi-même les BAL, néanmoins, dans le cadre d'un backup incrémental, ça doit pouvoir suffire.
D'après <http://www.eyrich-net.org/mozilla/X-Mozilla-Status.html?en>, c'est bien le 4è bit du champ "X-Mozilla-Status" qui indique si le message a été supprimé.
Voici donc ce que je compte faire :
Lors du backup complet sur DVD-R, je sauvegarde tous les messages non supprimés, tout en gardant la liste des hashs MD5 des messages effectivement sauvegardés. Lors du backup incrémental sur ZIP-750, j'enregistre les messages non supprimés, tout en remplaçant chaque "ancien" message (i.e. déjà sauvegardé sur DVD) par son hash MD5.
En théorie, cette méthode ne garantit pas une fiabilité à 100 %, mais la fiabilité est néanmoins très bonne, d'autant que le backup sur DVD+ZIP ne sert qu'en cas de destruction simultanée des deux disques durs du serveur.
Voilà voilà, promis, dès que j'ai moins de 18 mois de retard sur mon planning des choses à faire pour avant-hier dernier délai, je m'y mets ;-)
-- schtroumpf schtroumpf Jean-Emile de France
geo cherchetout
Le 09.07.2004 15:04, *FantasioMagazine* a écrit fort à propos :
la procédure utilisée par mozilla/netscape consiste à recréer un nouveau fichier et lui adjoindre les mails non-effacés.
Et à mettre à jour le ou les fichiers .msf, il me semble.
Le 09.07.2004 15:04, *FantasioMagazine* a écrit fort à propos :
la procédure utilisée par mozilla/netscape consiste à recréer un nouveau
fichier et lui adjoindre les mails non-effacés.
Et à mettre à jour le ou les fichiers .msf, il me semble.
Le 09.07.2004 15:04, *FantasioMagazine* a écrit fort à propos :
la procédure utilisée par mozilla/netscape consiste à recréer un nouveau fichier et lui adjoindre les mails non-effacés.
Et à mettre à jour le ou les fichiers .msf, il me semble.
Fabien LE LEZ
On Fri, 09 Jul 2004 05:36:11 +0200, Fabien LE LEZ :
Histoire d'économiser un peu d'espace (surtout que le tout arrive sur ZIP et DVD-R), j'aimerais un utilitaire en ligne de commande capable de compacter ces BAL (l'équivalent de ce que fait le menu "File -> Compact folders" dans Thunderbird).
Bon, ben finalement, ce fut moins compliqué que prévu. La version beta (pour Windows) est là : <http://perso.edulang.com/backup_thunderbird.1.0.zip>
Dans son fonctionnement le plus simple, le programme ne fait que compacter une boîte aux lettres :
La fonctionnalité plus avancée est adaptée à mon fonctionnement : je sauvegarde toutes les données une fois par semaine sur DVD-R, et je fais un backup incrémental quotidien sur ZIP.
Dans le fichier .backup_sur_ZIP, les emails déjà sauvegardés sur DVD sont remplacés par le MD5 correspondant. Note : inutile de copier le fichier .md5 sur ZIP ou DVD, il ne sert pas pour la récupération.
La récupération des données (en cas de crash du serveur) se fait par :
Le programme copie alors le fichier "Inbox.backup_sur_ZIP", en remplaçant les "raccourcis" MD5 par l'email complet récupéré dans "Inbox.backup_sur_DVD".
On Fri, 09 Jul 2004 05:36:11 +0200, Fabien LE LEZ
<gramster@gramster.com>:
Histoire d'économiser un peu d'espace (surtout que le tout arrive sur
ZIP et DVD-R), j'aimerais un utilitaire en ligne de commande capable
de compacter ces BAL (l'équivalent de ce que fait le menu "File ->
Compact folders" dans Thunderbird).
Bon, ben finalement, ce fut moins compliqué que prévu.
La version beta (pour Windows) est là :
<http://perso.edulang.com/backup_thunderbird.1.0.zip>
Dans son fonctionnement le plus simple, le programme ne fait que
compacter une boîte aux lettres :
La fonctionnalité plus avancée est adaptée à mon fonctionnement : je
sauvegarde toutes les données une fois par semaine sur DVD-R, et je
fais un backup incrémental quotidien sur ZIP.
Dans le fichier .backup_sur_ZIP, les emails déjà sauvegardés sur DVD
sont remplacés par le MD5 correspondant. Note : inutile de copier le
fichier .md5 sur ZIP ou DVD, il ne sert pas pour la récupération.
La récupération des données (en cas de crash du serveur) se fait par :
Le programme copie alors le fichier "Inbox.backup_sur_ZIP", en
remplaçant les "raccourcis" MD5 par l'email complet récupéré dans
"Inbox.backup_sur_DVD".
On Fri, 09 Jul 2004 05:36:11 +0200, Fabien LE LEZ :
Histoire d'économiser un peu d'espace (surtout que le tout arrive sur ZIP et DVD-R), j'aimerais un utilitaire en ligne de commande capable de compacter ces BAL (l'équivalent de ce que fait le menu "File -> Compact folders" dans Thunderbird).
Bon, ben finalement, ce fut moins compliqué que prévu. La version beta (pour Windows) est là : <http://perso.edulang.com/backup_thunderbird.1.0.zip>
Dans son fonctionnement le plus simple, le programme ne fait que compacter une boîte aux lettres :
La fonctionnalité plus avancée est adaptée à mon fonctionnement : je sauvegarde toutes les données une fois par semaine sur DVD-R, et je fais un backup incrémental quotidien sur ZIP.
Dans le fichier .backup_sur_ZIP, les emails déjà sauvegardés sur DVD sont remplacés par le MD5 correspondant. Note : inutile de copier le fichier .md5 sur ZIP ou DVD, il ne sert pas pour la récupération.
La récupération des données (en cas de crash du serveur) se fait par :
Le programme copie alors le fichier "Inbox.backup_sur_ZIP", en remplaçant les "raccourcis" MD5 par l'email complet récupéré dans "Inbox.backup_sur_DVD".
Fabien LE LEZ
On Sat, 10 Jul 2004 14:01:21 +0200, Fabien LE LEZ :
La version beta (pour Windows) est là : <http://perso.edulang.com/backup_thunderbird.1.0.zip>
Note : ça a l'air de fonctionner, mais rien n'est garanti. Si quelqu'un veut tester... merci d'avance ! ;-)
On Sat, 10 Jul 2004 14:01:21 +0200, Fabien LE LEZ
<gramster@gramster.com>:
La version beta (pour Windows) est là :
<http://perso.edulang.com/backup_thunderbird.1.0.zip>
Note : ça a l'air de fonctionner, mais rien n'est garanti. Si
quelqu'un veut tester... merci d'avance ! ;-)
On Sat, 10 Jul 2004 14:01:21 +0200, Fabien LE LEZ :
La version beta (pour Windows) est là : <http://perso.edulang.com/backup_thunderbird.1.0.zip>
Note : ça a l'air de fonctionner, mais rien n'est garanti. Si quelqu'un veut tester... merci d'avance ! ;-)
J'ai fait quelques tests, ça à l'air ok.
Question vitesse c'est beaucoup + rapide que thunderburd
Sur mon fichier inbox de 210 Mo ton outil prend 21 s, et Mozilla 1.6 prend 2 min
Une comparaison des 2 fichiers (traités par mozilla ou ton programme) ne révèle aucune différence (comp fichier1 fichier2).
bien.
Fabien LE LEZ
On Mon, 12 Jul 2004 11:12:41 +0200, FantasioMagazine :
J'ai fait quelques tests, ça à l'air ok.
Cool :-)
Pourrais-tu tester également la fonction "backup incrémental" ?
En gros, aujourd'hui tu utilises la commande "create_md5", et d'ici quelques jours d'utilisation intense de Thunderbird, tu utilises "use_md5", puis juste après "restore" pour vérifier que tu obtiens bien le même fichier. Merci d'avance... :-)
Note : je vais bien sûr tester assez intensivement un de ces jours [après tout, j'ai fait cet utilitaire parce que j'en ai besoin ;-) ], mais l'expérience montre qu'une deuxième personne, non impliquée dans le développement, trouve toujours des bugs supplémentaires, passés inaperçus aux yeux du programmeur.
Question vitesse c'est beaucoup + rapide que thunderburd
C'est normal : les fonctions de gestion de fichiers de la bibliothèque standard C (fopen() et compagnie) sont mal implémentées sur la plupart des compilos. Du coup, comme je cherchais à faire un programme Windows uniquement[*], j'ai utilisé directement les fonctions natives de l'API (CreateFile() & co.).
[*] Il est vraisemblablement compilable sur d'autres systèmes, mais pas avec les mêmes performances.
Une comparaison des 2 fichiers (traités par mozilla ou ton programme) ne révèle aucune différence (comp fichier1 fichier2).
Tiens, ça existe toujours, "comp" ? Je croyais que sous Windows 2000, il avait été remplacé par "fc"...
On Mon, 12 Jul 2004 11:12:41 +0200, FantasioMagazine
<pasdespam@bill.net>:
J'ai fait quelques tests, ça à l'air ok.
Cool :-)
Pourrais-tu tester également la fonction "backup incrémental" ?
En gros, aujourd'hui tu utilises la commande "create_md5", et d'ici
quelques jours d'utilisation intense de Thunderbird, tu utilises
"use_md5", puis juste après "restore" pour vérifier que tu obtiens
bien le même fichier.
Merci d'avance... :-)
Note : je vais bien sûr tester assez intensivement un de ces jours
[après tout, j'ai fait cet utilitaire parce que j'en ai besoin ;-) ],
mais l'expérience montre qu'une deuxième personne, non impliquée dans
le développement, trouve toujours des bugs supplémentaires, passés
inaperçus aux yeux du programmeur.
Question vitesse c'est beaucoup + rapide que thunderburd
C'est normal : les fonctions de gestion de fichiers de la bibliothèque
standard C (fopen() et compagnie) sont mal implémentées sur la plupart
des compilos.
Du coup, comme je cherchais à faire un programme Windows
uniquement[*], j'ai utilisé directement les fonctions natives de l'API
(CreateFile() & co.).
[*] Il est vraisemblablement compilable sur d'autres systèmes, mais
pas avec les mêmes performances.
Une comparaison des 2 fichiers (traités par mozilla ou ton programme)
ne révèle aucune différence (comp fichier1 fichier2).
Tiens, ça existe toujours, "comp" ?
Je croyais que sous Windows 2000, il avait été remplacé par "fc"...
On Mon, 12 Jul 2004 11:12:41 +0200, FantasioMagazine :
J'ai fait quelques tests, ça à l'air ok.
Cool :-)
Pourrais-tu tester également la fonction "backup incrémental" ?
En gros, aujourd'hui tu utilises la commande "create_md5", et d'ici quelques jours d'utilisation intense de Thunderbird, tu utilises "use_md5", puis juste après "restore" pour vérifier que tu obtiens bien le même fichier. Merci d'avance... :-)
Note : je vais bien sûr tester assez intensivement un de ces jours [après tout, j'ai fait cet utilitaire parce que j'en ai besoin ;-) ], mais l'expérience montre qu'une deuxième personne, non impliquée dans le développement, trouve toujours des bugs supplémentaires, passés inaperçus aux yeux du programmeur.
Question vitesse c'est beaucoup + rapide que thunderburd
C'est normal : les fonctions de gestion de fichiers de la bibliothèque standard C (fopen() et compagnie) sont mal implémentées sur la plupart des compilos. Du coup, comme je cherchais à faire un programme Windows uniquement[*], j'ai utilisé directement les fonctions natives de l'API (CreateFile() & co.).
[*] Il est vraisemblablement compilable sur d'autres systèmes, mais pas avec les mêmes performances.
Une comparaison des 2 fichiers (traités par mozilla ou ton programme) ne révèle aucune différence (comp fichier1 fichier2).
Tiens, ça existe toujours, "comp" ? Je croyais que sous Windows 2000, il avait été remplacé par "fc"...
