Lors que je d=E9place un message d'un r=E9pertoire IMAP =E0 un autre (B m),
celui-ci n'est pas effac=E9 de la bo=EEte d'origine. Je dois faire B Suppr =
en
plus.
Suis-je le seul =E0 rencontrer ce probl=E8me=A0? Auriez-vous une
explication/solution=A0?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bastien
Prakash Countcham writes:
Lors que je déplace un message d'un répertoire IMAP à un autre (B m), celui-ci n'est pas effacé de la boîte d'origine. Je dois faire B Suppr en plus.
Je pense que ça peut aider:
,----[ (info "(gnus)IMAP") ] | `nnimap-expunge-on-close' | Unlike Parmenides the IMAP designers have decided things that | don't exist actually do exist. More specifically, IMAP has this | concept of marking articles `Deleted' which doesn't actually | delete them, and this (marking them `Deleted', that is) is what | nnimap does when you delete an article in Gnus (with `B DEL' or | similar). | | Since the articles aren't really removed when we mark them with the | `Deleted' flag we'll need a way to actually delete them. Feel like | running in circles yet? | | Traditionally, nnimap has removed all articles marked as `Deleted' | when closing a mailbox but this is now configurable by this server | variable. | | The possible options are: | | `always' | The default behavior, delete all articles marked as "Deleted" | when closing a mailbox. | | `never' | Never actually delete articles. Currently there is no way of | showing the articles marked for deletion in nnimap, but other | IMAP clients may allow you to do this. If you ever want to | run the EXPUNGE command manually, *Note Expunging mailboxes::. | | `ask' | When closing mailboxes, nnimap will ask if you wish to | expunge deleted articles or not. `----
Lors que je déplace un message d'un répertoire IMAP à un autre (B
m), celui-ci n'est pas effacé de la boîte d'origine. Je dois faire B
Suppr en plus.
Je pense que ça peut aider:
,----[ (info "(gnus)IMAP") ]
| `nnimap-expunge-on-close'
| Unlike Parmenides the IMAP designers have decided things that
| don't exist actually do exist. More specifically, IMAP has this
| concept of marking articles `Deleted' which doesn't actually
| delete them, and this (marking them `Deleted', that is) is what
| nnimap does when you delete an article in Gnus (with `B DEL' or
| similar).
|
| Since the articles aren't really removed when we mark them with the
| `Deleted' flag we'll need a way to actually delete them. Feel like
| running in circles yet?
|
| Traditionally, nnimap has removed all articles marked as `Deleted'
| when closing a mailbox but this is now configurable by this server
| variable.
|
| The possible options are:
|
| `always'
| The default behavior, delete all articles marked as "Deleted"
| when closing a mailbox.
|
| `never'
| Never actually delete articles. Currently there is no way of
| showing the articles marked for deletion in nnimap, but other
| IMAP clients may allow you to do this. If you ever want to
| run the EXPUNGE command manually, *Note Expunging mailboxes::.
|
| `ask'
| When closing mailboxes, nnimap will ask if you wish to
| expunge deleted articles or not.
`----
Lors que je déplace un message d'un répertoire IMAP à un autre (B m), celui-ci n'est pas effacé de la boîte d'origine. Je dois faire B Suppr en plus.
Je pense que ça peut aider:
,----[ (info "(gnus)IMAP") ] | `nnimap-expunge-on-close' | Unlike Parmenides the IMAP designers have decided things that | don't exist actually do exist. More specifically, IMAP has this | concept of marking articles `Deleted' which doesn't actually | delete them, and this (marking them `Deleted', that is) is what | nnimap does when you delete an article in Gnus (with `B DEL' or | similar). | | Since the articles aren't really removed when we mark them with the | `Deleted' flag we'll need a way to actually delete them. Feel like | running in circles yet? | | Traditionally, nnimap has removed all articles marked as `Deleted' | when closing a mailbox but this is now configurable by this server | variable. | | The possible options are: | | `always' | The default behavior, delete all articles marked as "Deleted" | when closing a mailbox. | | `never' | Never actually delete articles. Currently there is no way of | showing the articles marked for deletion in nnimap, but other | IMAP clients may allow you to do this. If you ever want to | run the EXPUNGE command manually, *Note Expunging mailboxes::. | | `ask' | When closing mailboxes, nnimap will ask if you wish to | expunge deleted articles or not. `----
-- Bastien
Prakash Countcham
Bastien writes:
Je pense que ça peut aider:
Malheureusement, non :(
| `always' | The default behavior, delete all articles marked as "Deleted" | when closing a mailbox.
La valeur de nnimap-expunge-on-close est effectivement always. Et je m'attends à ce que le message soit effacé.
Je précise que même après un gnus-agent-expire, le message est toujou rs présent.
Aurais-tu d'autres idées ? Amicalement,
-- Prakash
Bastien <bastien@xxx.fr> writes:
Je pense que ça peut aider:
Malheureusement, non :(
| `always'
| The default behavior, delete all articles marked as "Deleted"
| when closing a mailbox.
La valeur de nnimap-expunge-on-close est effectivement always. Et je
m'attends à ce que le message soit effacé.
Je précise que même après un gnus-agent-expire, le message est toujou rs
présent.
Je viens d'essayer chez moi, et ça marche normalement (avec la même version de Gnus que toi) - donc à court d'idée pour l'instant, désolé!
-- Bastien
Jean Magnan de Bornier
Le 18 novembre à 18:31:35 Prakash Countcham écrit notamment:
Bastien writes:
Je pense que ça peut aider:
Malheureusement, non :(
| `always' | The default behavior, delete all articles marked as "Deleted" | when closing a mailbox.
La valeur de nnimap-expunge-on-close est effectivement always. Et je m'attends à ce que le message soit effacé.
Je précise que même après un gnus-agent-expire, le message est touj ours présent.
Pas d'idée, mais j'ai aussi ce problème avec aussi nnimap-expunge-on-cl ose à always. No Gnus v0.4
Au moins Prakash tu n'es pas seul! à+, -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87
Le 18 novembre à 18:31:35 Prakash Countcham <rf.gami@mahctnuoc.hsakarp>
écrit notamment:
Bastien <bastien@xxx.fr> writes:
Je pense que ça peut aider:
Malheureusement, non :(
| `always'
| The default behavior, delete all articles marked as "Deleted"
| when closing a mailbox.
La valeur de nnimap-expunge-on-close est effectivement always. Et je
m'attends à ce que le message soit effacé.
Je précise que même après un gnus-agent-expire, le message est touj ours
présent.
Pas d'idée, mais j'ai aussi ce problème avec aussi nnimap-expunge-on-cl ose
à always.
No Gnus v0.4
Au moins Prakash tu n'es pas seul!
à+,
--
Jean Magnan de Bornier | Cours Victor Hugo
e-mots: jean at bornier.net | 13980 Alleins France
T 08 70 39 34 03 | P 06 09 17 35 87
Le 18 novembre à 18:31:35 Prakash Countcham écrit notamment:
Bastien writes:
Je pense que ça peut aider:
Malheureusement, non :(
| `always' | The default behavior, delete all articles marked as "Deleted" | when closing a mailbox.
La valeur de nnimap-expunge-on-close est effectivement always. Et je m'attends à ce que le message soit effacé.
Je précise que même après un gnus-agent-expire, le message est touj ours présent.
Pas d'idée, mais j'ai aussi ce problème avec aussi nnimap-expunge-on-cl ose à always. No Gnus v0.4
Au moins Prakash tu n'es pas seul! à+, -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87
Sébastien Kirche
Le 18 novembre 2005 à 23:11, Jean Magnan de Bornier vraute :
Pas d'idée, mais j'ai aussi ce problème avec aussi nnimap-expunge-on-close à always. No Gnus v0.4
Au moins Prakash tu n'es pas seul!
Pareil. Mais ce n'est pas systématique. Parfois c'est le dernier message qui ne veut pas se supprimer, par exemple en déplaçant l'ensemble des messages d'un summary.
Même valeur de nnimap-expunge-on-close et NoGnus 0.4 -- Sébastien Kirche
Le 18 novembre 2005 à 23:11, Jean Magnan de Bornier vraute :
Pas d'idée, mais j'ai aussi ce problème avec aussi
nnimap-expunge-on-close à always. No Gnus v0.4
Au moins Prakash tu n'es pas seul!
Pareil. Mais ce n'est pas systématique. Parfois c'est le dernier message
qui ne veut pas se supprimer, par exemple en déplaçant l'ensemble des
messages d'un summary.
Même valeur de nnimap-expunge-on-close et NoGnus 0.4
--
Sébastien Kirche
Le 18 novembre 2005 à 23:11, Jean Magnan de Bornier vraute :
Pas d'idée, mais j'ai aussi ce problème avec aussi nnimap-expunge-on-close à always. No Gnus v0.4
Au moins Prakash tu n'es pas seul!
Pareil. Mais ce n'est pas systématique. Parfois c'est le dernier message qui ne veut pas se supprimer, par exemple en déplaçant l'ensemble des messages d'un summary.
Même valeur de nnimap-expunge-on-close et NoGnus 0.4 -- Sébastien Kirche
Bastien
Prakash Countcham writes:
Lors que je déplace un message d'un répertoire IMAP à un autre (B m), celui-ci n'est pas effacé de la boîte d'origine. Je dois faire B Suppr en plus.
En lisant , la solution serait apparemment de faire ça:
Lors que je déplace un message d'un répertoire IMAP à un autre (B m), celui-ci n'est pas effacé de la boîte d'origine. Je dois faire B Suppr en plus.
En lisant , la solution serait apparemment de faire ça:
(setq gnus-fetch-old-headers nil)
-- Bastien
Prakash Countcham
Bastien writes:
Prakash Countcham writes:
Lors que je déplace un message d'un répertoire IMAP à un autre (B m), celui-ci n'est pas effacé de la boîte d'origine. Je dois faire B Suppr en plus.
En lisant , la solution serait apparemment de faire ça:
(setq gnus-fetch-old-headers nil)
Merci, cela règle effectivement le problème du déplacement des messag es. Mais je ne vois pas très bien le rapport entre le déplacement des messages, et cette option.
Lors que je déplace un message d'un répertoire IMAP à un autre (B
m), celui-ci n'est pas effacé de la boîte d'origine. Je dois faire B
Suppr en plus.
En lisant ding@gnus.org, la solution serait apparemment de faire ça:
(setq gnus-fetch-old-headers nil)
Merci, cela règle effectivement le problème du déplacement des messag es. Mais
je ne vois pas très bien le rapport entre le déplacement des messages, et
cette option.
Lors que je déplace un message d'un répertoire IMAP à un autre (B m), celui-ci n'est pas effacé de la boîte d'origine. Je dois faire B Suppr en plus.
En lisant , la solution serait apparemment de faire ça:
(setq gnus-fetch-old-headers nil)
Merci, cela règle effectivement le problème du déplacement des messag es. Mais je ne vois pas très bien le rapport entre le déplacement des messages, et cette option.
Amicalement,
-- Prakash
Bastien
Prakash Countcham writes:
En lisant , la solution serait apparemment de faire ça:
(setq gnus-fetch-old-headers nil)
Merci, cela règle effectivement le problème du déplacement des messages. Mais je ne vois pas très bien le rapport entre le déplacement des messages, et cette option.
Voici les mails qui en parlent, je ne suis pas allé voir plus loin.
,----[ Danny Siu ] | I looked into this problem a little more and found that setting | gnus-fetch-old-headers to 'nil will fix it. ie: 'B m' will delete | the moved article from the source group. I think the header fetch | is bypassing the agent code and that results in some inconsistent | NOV entries in the agent cache. `----
,----[ "Kevin Greiner" ] | Well, that's nice to hear. I just ran into gnus-fetch-old-headers | earlier this week. This variable is used by the nntp backend to | override the list of requested headers to fetch a subset. The | problem that was previously reported was that gnus fetched the | same headers each time it entered a group because (of course) it | bypassed the agent. | | Now, you've run into a similar problem with nnml. Hmmm... It | looks like nnml simulates the nov database with a local file of | article headers. Apparently, the 'B m' command fails to update | this file as a subsequent call to retrieve header with gnus-fetch- | old-headers fetches the article's old header. | | Unless someone volunteers, I'll see what can be done with the 'B | m' command to keep the nnml nov file in sync. `----
En lisant ding@gnus.org, la solution serait apparemment de faire ça:
(setq gnus-fetch-old-headers nil)
Merci, cela règle effectivement le problème du déplacement des messages. Mais
je ne vois pas très bien le rapport entre le déplacement des messages, et
cette option.
Voici les mails qui en parlent, je ne suis pas allé voir plus loin.
,----[ Danny Siu <dsiu@adobe.com> ]
| I looked into this problem a little more and found that setting
| gnus-fetch-old-headers to 'nil will fix it. ie: 'B m' will delete
| the moved article from the source group. I think the header fetch
| is bypassing the agent code and that results in some inconsistent
| NOV entries in the agent cache.
`----
,----[ "Kevin Greiner" <kevin.greiner@compsol.cc> ]
| Well, that's nice to hear. I just ran into gnus-fetch-old-headers
| earlier this week. This variable is used by the nntp backend to
| override the list of requested headers to fetch a subset. The
| problem that was previously reported was that gnus fetched the
| same headers each time it entered a group because (of course) it
| bypassed the agent.
|
| Now, you've run into a similar problem with nnml. Hmmm... It
| looks like nnml simulates the nov database with a local file of
| article headers. Apparently, the 'B m' command fails to update
| this file as a subsequent call to retrieve header with gnus-fetch-
| old-headers fetches the article's old header.
|
| Unless someone volunteers, I'll see what can be done with the 'B
| m' command to keep the nnml nov file in sync.
`----
En lisant , la solution serait apparemment de faire ça:
(setq gnus-fetch-old-headers nil)
Merci, cela règle effectivement le problème du déplacement des messages. Mais je ne vois pas très bien le rapport entre le déplacement des messages, et cette option.
Voici les mails qui en parlent, je ne suis pas allé voir plus loin.
,----[ Danny Siu ] | I looked into this problem a little more and found that setting | gnus-fetch-old-headers to 'nil will fix it. ie: 'B m' will delete | the moved article from the source group. I think the header fetch | is bypassing the agent code and that results in some inconsistent | NOV entries in the agent cache. `----
,----[ "Kevin Greiner" ] | Well, that's nice to hear. I just ran into gnus-fetch-old-headers | earlier this week. This variable is used by the nntp backend to | override the list of requested headers to fetch a subset. The | problem that was previously reported was that gnus fetched the | same headers each time it entered a group because (of course) it | bypassed the agent. | | Now, you've run into a similar problem with nnml. Hmmm... It | looks like nnml simulates the nov database with a local file of | article headers. Apparently, the 'B m' command fails to update | this file as a subsequent call to retrieve header with gnus-fetch- | old-headers fetches the article's old header. | | Unless someone volunteers, I'll see what can be done with the 'B | m' command to keep the nnml nov file in sync. `----
