On Sun, Feb 13 2022, Tomi Ollila wrote: > On Sat, Feb 12 2022, David Bremner wrote: > >> Tomi Ollila <tomi.oll...@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 -- firstname.lastname@example.org To unsubscribe send an email to notmuch-le...@notmuchmail.org