Hi Stan,
> Mutt's current behavior is consistent with elm and other mailers.
> This is traditional mbox behavior. I happen to like it.
Are there RFCs or something like that?
That is has always been so doesn't necessarily mean that it's correct.
> > Great! Developers, will you change it then? :
Mutt's current behavior is consistent with elm and other mailers.
This is traditional mbox behavior. I happen to like it.
> Great! Developers, will you change it then? :-)
I hope not. There is no need to have the mtime to be updated
every time the ctime is updated. (Or, if there is such a ne
Hi Matt,
> My reasoning is close to Luke's: to support legacy mail notification
> programs.
I thought about that, too. I think the change whouldn't affect bash if
mutt only keeps the timestamp of the incoming mailbox /var/mail/..., right?
> However, I see your point. I wasn't really thinking a
* Andy Spiegl <[EMAIL PROTECTED]> [010719 15:08]:
> > > Noone objected - does that mean that the code will be removed in the next
> > > release? If no, what do I have to do so that it will be removed?
> >
> > I'll throw in my objection then. You're proposing something like this??
> Yes.
>
>
> > Noone objected - does that mean that the code will be removed in the next
> > release? If no, what do I have to do so that it will be removed?
>
> I'll throw in my objection then. You're proposing something like this??
Yes.
> I think mutt should restore the a/m times.
Hm, and why do you
Hi,
On Wed, Jul 18, 2001 at 11:50:19AM -0500, Andy Spiegl wrote:
>
> Noone objected - does that mean that the code will be removed in the next
> release? If no, what do I have to do so that it will be removed?
As I touched upon before, I'll be unhappy if it breaks my bash new mail
notificat
* Andy Spiegl <[EMAIL PROTECTED]> [010718 12:58]:
> > > Might be helpful with some naive new-mail checking programs, but of
> > > course breaks mechanisms which really look for mailbox updates.
> > I vote for removing the code. (c:
> > Anyone objects?
>
> Noone objected - does that mean that th
> > Might be helpful with some naive new-mail checking programs, but of
> > course breaks mechanisms which really look for mailbox updates.
> I vote for removing the code. (c:
> Anyone objects?
Noone objected - does that mean that the code will be removed in the next
release? If no, what do
* Matt Dunford <[EMAIL PROTECTED]> [010707 16:54]:
>
> I'm experiencing a similar problem. My mailboxes count fluctuates as I
> browse through my mailboxes. Here's a snippit from my .muttrc:
>
> set status_format="%v: %f%r [%M/%m] [N=%n,*=%t,post=%p,boxes=%b] %?V?{%V}?"
> mailboxes ! =ancientb
Depends on what kind of heuristic bash applies.
On 2001-07-11 21:29:23 +0100, Luke Ross wrote:
>Date: Wed, 11 Jul 2001 21:29:23 +0100
>From: Luke Ross <[EMAIL PROTECTED]>
>To: Mutt User List <[EMAIL PROTECTED]>
>Subject: Re: timestamp of mailbox file is not updated
&
Hi
> > Might be helpful with some naive new-mail checking programs, but of
> > course breaks mechanisms which really look for mailbox updates.
> I vote for removing the code. (c:
> Anyone objects?
Will it affect bash telling me I have new mail? (As in, it'll say I do
every time I quit mutt?)
> In order to remove this behaviour, you'd just have to comment out
> lines 960-965 in mbox.c.
Ah, great. Hm, but what will I break doing that? :-)
> Thinking about it, the code in question makes sure that an mbox
> folder's mtime is always the point of time at which the last message
> was _a
On 2001-07-10 19:08:27 -0500, Andy Spiegl wrote:
>> >> hamster:~>l testmailbox
>> >> -rw---1 spiegl users 26537 Feb 20 20:57 testmailbox
>[...]
>> >> hamster:~>l testmailbox
>> >> -rw---1 spiegl users 26579 Feb 20 20:57 testmailbox
>[...]
>> >> hamster:~>l testmail
On 2001-07-10 19:08:27 -0500, Andy Spiegl wrote:
>By the way you are also wrong about the proof of the 60 seconds.
>:-) I had done this test not 5 months ago, but very recently.
>Only the timestamp of the file is from February!
Thinking about it, the code in question makes sure that an mbox
f
I was going to ask for what your alias was, but I went and
tried it myself. ls -l shows the same effect!
On Tue, Jul 10, 2001 at 07:08:27PM -0500, Andy Spiegl wrote:
> By the way you are also wrong about the proof of the 60 seconds. :-)
> I had done this test not 5 months ago, but very recently.
I have also noticed that mbox mailbox files' modification times
seem not to be updated when messages are deleted. Whenever a
message is added, the file's modification time is updated,
though. Unfortunately, I have no idea why.
Andy Spiegl <[EMAIL PROTECTED]> wrote:
> Hi Mutters,
>
> I am gradu
> All you have been proving so far is that mutt is able to read and
> rewrite a 4-message, 20k mailbox within less than 60 seconds...
N, I have also proven that the timestamp is the same BEFORE and AFTER
opening and changing the contents of the mailbox:
> >> hamster:~>l testmailbox
> >> -rw
To: Mutt User List <[EMAIL PROTECTED]>
>Subject: Re: timestamp of mailbox file is not updated
>Mail-Followup-To: Mutt User List <[EMAIL PROTECTED]>
>User-Agent: Mutt/1.3.15i
>Organization: Radio Marañón, Peru
>
>Hi Mutters,
>
>I am gradually getting concerned that n
Hi Mutters,
I am gradually getting concerned that no one is caring about this bug (if
it's a bug and not a strange feature). Please let me know if there is
something I can do to change this strange behaviur of mutt. I can't find
anything in the manual and FAQ. Hope I didn't overlook anything.
* Andy Spiegl <[EMAIL PROTECTED]> [010706 17:16]:
> Hi Mutters,
>
> I found it very strange to find out that mutt sometimes doesn't update the
> timestamp of a mailbox file. Here's an example:
>
> [...] *snip*
>
> Is there a specific reason for this behaviour? Or could it be a
> configuration
20 matches
Mail list logo
