|
|
 | | From: | D P Schreber | | Subject: | that (index) N-flag bug again | | Date: | 15 Dec 2004 17:17:20 GMT |
|
|
 | Well, I've yet to see this bug after several days of heavy mutt usage
in which I was specifically looking for it. Either I'm not looking for
the right symptom or this bug is not intrinsic to mutt in osx but is
rather being caused by configuration-specific factors.
|
|
| | From: | Christian Ebert | | Subject: | Re: that (index) N-flag bug again | | Date: | Thu, 16 Dec 2004 09:37:18 +0100 |
|
|
| * D P Schreber on Wed, Dec 15, 2004:
> Well, I've yet to see this bug after several days of heavy mutt usage
> in which I was specifically looking for it.
The issue, or not having the issue, is buggin you? ;-) I don't
mind looking into this a bit more. I believe the first and best
test is to check the results of Alain's access time script
Message-ID: :
$ ls -ul testmbox; cat testmbox >/dev/null; date; ls -ul testmbox
On my machine access time is not changed. I took this as
explanation for mutt's behaviour to be caused by the system's
handling of atime.
If you get different atimes when running above script IMO it
would explain that you don't experience the problem, but that
apparently you have some different system
settings/configurations. I have no idea why your machine would
react differently (Chris Menzel also got same atime) but if you
got proposals what to check I'm willing to do so -- probably
better via PM because then it's more a Mac than a mutt issue.
On the other hand if you get same atimes too, I am at a loss, and
my only guess would be that it's because AFAIR you're doing
mostly IMAP, and I didn't have any probs with IMAP folders either
(of course, they are not on my machine).
> Either I'm not looking for the right symptom
The easiest way I've found to reproduce this is to send a mail to
yourself@localhost (make sure that it is dispatched to a mailbox
where it stays and doesn't get moved to $record automatically
after reading), then mutt -y, read the message,
to another mailbox and hit c for again. If I have
compiled w/o --enable-nfs-fix or --enable-buffy-size mutt offers
me the mailbox I just came from as having new mail.
> or this bug is not intrinsic to mutt in osx but is
> rather being caused by configuration-specific factors.
To judge by the name of the configure option it's at least
intrinsic for mutt on nfs-systems.
c
--
Der Feind ist unsere eigene Frage als Gestalt.
~ Carl Schmitt
|
|
| | From: | D P Schreber | | Subject: | Re: that (index) N-flag bug again | | Date: | 16 Dec 2004 15:06:14 GMT |
|
|
| On 2004-12-16, Christian Ebert wrote:
> The issue, or not having the issue, is buggin you? ;-)
Being neurotic in this way makes me a good software developer :) But I
have now finally seen this behavior, once (see below). So I can sleep
again....
> $ ls -ul testmbox; cat testmbox >/dev/null; date; ls -ul testmbox
Right, I reported my results on this earlier, though possibly with a
different pseudonym. I have the same problem as everyone else, and it
doesn't seem to be related to journaling.
Btw has this weirdness ever been discussed on c.s.m.system?
> On the other hand if you get same atimes too, I am at a loss, and my
> only guess would be that it's because AFAIR you're doing mostly IMAP
Looks like it was just a question of usage styles and timing. It didn't
occur to me during testing that I should switch mailboxes more or less
as quickly as possible. Once I did that, I was able to see the problem,
once anyway. If I read new mail in my usual way, I never see the bug:
by the time I've read a new message, selected some other mailbox,
selected and read some message or messages there, and switched back
again to the first mailbox, the N flag is fine.
In short, the time window for this N flag bug is small relative to my
standard mailbox-switching time.
> The easiest way I've found to reproduce this is to send a mail to
> yourself@localhost (make sure that it is dispatched to a mailbox where
> it stays and doesn't get moved to $record automatically after reading)
Isn't $record for outgoing mail? Anyway, I have $move set to 'no', so
once a message gets placed in a mailbox via procmail, it stays there
unless I move it or delete it manually.
|
|
| | From: | Karl Billeter | | Subject: | Re: that (index) N-flag bug again | | Date: | 22 Dec 2004 06:48:31 GMT |
|
|
| On 2004-12-16, D P Schreber wrote:
> On 2004-12-16, Christian Ebert wrote:
>> The issue, or not having the issue, is buggin you? ;-)
>
> Being neurotic in this way makes me a good software developer :) But I
> have now finally seen this behavior, once (see below). So I can sleep
> again....
I've had a similar problem (twice in 3 years) after upgrades on Debian. I
never got as far as a cause as the symptoms went away after doing a
cd ~/mail; touch *
Karl
|
|
|
