On Sun, Feb 13 2022, Tomi Ollila wrote:

> On Sat, Feb 12 2022, David Bremner wrote:
>
>> Tomi Ollila <tomi.ollila@iki.fi> writes:
>>
>>>
>>> Does such a change hide "buggy" functionality ?
>>
>> We mostly don't use add_message, call notmuch new via NOTMUCH_NEW in
>> T050-new.sh. So I think it would mostly not hide bugs in notmuch
>> new. OTOH, I'm surprised the same issues with timestamps don't show up
>> there, if that is really the problem.
>>
>>> Or do we consider notmuch new buggy if it does not notice all new messages
>>> arrived every time ?
>>
>> That's a harder question. Maybe? But I don't know how serious a bug it
>> is for actual users (who often get mail delivered in various concurrent
>> ways).
>
> The bug could be that the filesystem mtime resolution is 1 sec (hmm what
> is the resolution in database?), and 2 emails are delivered to one
> directory during one second -- and at the same time notmuch new is scanning
> emails and found only one of those. then no more emails are delivered to
> that one directory for a while -- so notmuch new does not find those.
>
> (now that I think of it that could happen to me :O -- just very improbable
> (or not, `stat .` outputs Modify: 2022-02-12 22:47:19.550838056 +0200) --
> have to check that timestamp resolution in database).

Looked notmuch-new.c -- time_t (seconds since epoch) is used as timestamp
comparisons (which would indicate the subsecond resolution most fs' provide
is not used)...

... and if so, I wonder why some of our tests are not failing all the time
for everyone...?

Tomi






>
> Tomi
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org