first for the important part:
while reading the source to find a place to put Brandon Long's "folder
count" patch. i've found a configure switch named "--enable-buffy-size"
that seems to solve the detection issue. i only browsed through the
source since it was quite late, but it seems to read the end of the
mbox to find out if the last message is a new one. so it partially
scans the mbox file. i guess i can extend that to a full scan to
report real numbers.
but at least it partially solves the detection issue.
On Sun, Jan 21, 2001 at 08:07:58PM +0000, Dave Pearson wrote:
> On Sun, Jan 21, 2001 at 06:44:54PM +0100, Heinrich Langos wrote:
> > On Sun, Jan 21, 2001 at 03:59:22PM +0000, Dave Pearson wrote:
[...]
> > > Saving such information won't help you work out how many new mails there
> > > are, or if there is new mail at all. It would let you know if the
> > > mailbox had been modified in some way, which is pretty much what mutt
> > > does right now.
> >
> > nope ... right now mutt only shows that the mailbox has been accessed. not
> > if it has been modified.
>
> It would appear that we have different definitions of "accessed" and
> "modified". My copy of mutt shows me when an mbox has been modified, not
> when it has been accessed.
do me a favor and check your "mutt -v" output. if it says
"+BUFFY_SIZE" than your mutt is not just checking access times but
much more than that. if it says "-BUFFY_SIZE" (like mine did) and
after grep-ing your mailbox still shows an "N", i don't get it.
grep doesn't modify your mbox.
so says strace:
open("/var/spool/mail/heinrich", O_RDONLY|0x8000) = 3
(though i have to admit i didn't find out what the 0x8000 part means
in a quick look at /usr/include/*)
BTW: is your mutt running 24/7 or do you start it anew in the morning
like i do... ( and several times a day whenever i've found a new
feature in mutt that i would like to try out ? :) )
> > right now a simple grep will screw up new mail detection.
> >
> > try this:
> > $ echo blah | mail yourself@localhost
> > $ grep something /var/spool/mail/yourself
> > $ mutt -y
> > and you see no "N" ... pretty sad, isn't it?
>
> No, I don't find it sad, I find it consistent with the documentation.
consistent? yes! i admit it is....
consistent with a documentation that says: in some cases new mail
detection is not working as one would expect, because there is evil in
world and "Something is rotten in the state of Denmark" :-)
> Obviously you're more than happy to find it an itch worth scratching, feel
> free to scratch it. All I've been saying is that it *is* reliable, it does
> exactly what it says it does. That it doesn't do what you'd like is a
> different matter, I'm not commenting on that.
it's not only me who wants mutt to behave that way, i guess.
if it was not the intention to make mutt detect new mail it would say
"... the main menu status bar displays how any of these folders have
been modified since they where accessed by some programm." ;-)
> > i'm not saying that mutt should constantly scan the whole mailboxes or
> > anything like that. i just say it could do so on request. or on startup.
>
> The problem with such a scan is that it could take ages. I've got a lot of
> mailboxes, some of which can be huge.
it only scans mailboxes that are marked as incoming mailboxes.
so it would do the same thing it does, when opening that mbox. only to
all of them at once... ok ok .. that would be some overhead.
but it will not scan all your mailboxes. especially not those archive
like things where you keep several years of the kernel developers list
or bugtraq :-)
if you keep your incoming mboxes down to a month back or two, it
shouldn't be such a problem. and the results of scanning can be cached
(just in memory or in a status file) and only refreshed if the file
was modified.
with _you_ chosing your favorite or most reliable way you see fit to
detect modification. be it access/modification time, file size
or md5sum.
any volunteers to go for it? i have to finish a studies project before
i can go for more than a quick'n'dirty hack.
-heinrich
--
Heinrich Langos <[EMAIL PROTECTED]>
pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc
_________________________________________________________________
|o| The reason we come up with new versions is not to fix bugs. |o|
|o| It's absolutely not. It's the stupidest reason to buy a new |o|
|o| version I ever heard. -- Bill Gates, Microsoft Corporation |o|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
