On Fri, 11 Jun 2004, Mark Crispin wrote: > On Fri, 11 Jun 2004, Tomas Pospisek's Mailing Lists wrote: > > The problem I'm fighting against here is that when reopening a connection > > the c-client's mh driver will loose knowledge of which messages were > > removed. > > That problem is insurmountable. > > If it is a problem for you, the solution is simple: do not use mh format.
Let me see what my users will answer me. > > And wrt *that* "flag", my sources seem to be clear - a removed message is > > prepended with a ',' or with a '#' [1] (that's what one of the mh users is > > seeing in RL as well). > > Like POP style deletion, what mh calls "deletion" seems similar to IMAP > deletion (and c-client implements strict IMAP semantics). That similarity > is deceptive. Once you do a careful study of how mh actually works and > what IMAP requires, it becomes clear that it is impossible to implement > the IMAP semantics of deletion using mh deletion. There is a difference > between "working some of the time" and "working all the time"; and it is > not an option to deviate from strict compliance with IMAP requirements. > > If it was possible to do it, I would have done it 12 years ago. > > The solution is not to use mh format. So it's better to leave the mh driver broken and very hard to use in a useful way, because it would not be possible to make it "strictly IMAP semantics compliant" (presonally it's still not clear why). *Is* the mh driver "strictly IMAP semantics compiant" right now? Is the fact that a) it forgets about all the flags and b) when reusing an open connection it just forgets about all the deleted messages "strictly IMAP semantics compliant"? Would it make the situation worse to fix that behaveour? *t -- ----------------------------------------------------------- Tomas Pospisek http://sourcepole.com - Linux & Open Source Solutions -----------------------------------------------------------