Re: Is there a reason why the trashed flag is not synced?
On Tue, May 11, 2021 at 08:48:45AM +0200, Michael J Gruber wrote: > If you sync gmail labels to exact copies in different folders then you're not > holding it right, sorry ;) > Gmail is not an IMAP service; it has an IMAP API which exposes labels as > folders, with all the caveats which this implies. That's why there are > better ways to sync Gmail with a notmuch mail store (gmailieer). Better is always a relative term. I prefer a standardized protocol over some homebrew stuff. > I don't think notmuch should break its design principle (1 message id, 1 > message) just to work around a problem caused by a wrong sync procedure: > that "delete instruction" is a result (merely: artifact) of speaking IMAP to > Gmail. It's not only gmail, really any IMAP server. If you have a message in multiple folders at the same time (which is entirely reasonable, think "todo" + where it actually should go after processing). They all have the same message ID. Only because you delete the copy from todo doesn't mean that you want it gone from other places as well. Sure, you could move instead of copying... But that means that you may now need to hunt through multiple folders instead of being able to grab the message from the actual mbox it should be in. IMAP doesn't impose a workflow, just because yours happens to be a certain way doesn't make it the gold standard ;) Cheers, Reto ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] test: change database from within pre-new hook
Michael J Gruber writes: > Due to the change in the config system, notmuch keeps a notmuch database > open when it would not do so before. Consequently, it can miss changes > to the database which are done from a hook (while notmuch holds the > databse in read only mode). When notmuch itself writes to the database > after that it uses wrong assumptions about the last used doc id etc. > > Demonstrate this by triggering an assertion. (This new test succeeds > with notmuch 0.31.4.) > > Signed-off-by: Michael J Gruber > --- > test/T400-hooks.sh | 21 + > 1 file changed, 21 insertions(+) > +notmuch search '*' > change.expected That line looks like leftover debugging to me, so I deleted it. Otherwise it works fine, thanks for tracking down the bug and providing a test. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH] test: change database from within pre-new hook
Due to the change in the config system, notmuch keeps a notmuch database
open when it would not do so before. Consequently, it can miss changes
to the database which are done from a hook (while notmuch holds the
databse in read only mode). When notmuch itself writes to the database
after that it uses wrong assumptions about the last used doc id etc.
Demonstrate this by triggering an assertion. (This new test succeeds
with notmuch 0.31.4.)
Signed-off-by: Michael J Gruber
---
test/T400-hooks.sh | 21 +
1 file changed, 21 insertions(+)
diff --git a/test/T400-hooks.sh b/test/T400-hooks.sh
index 00c99337..58e2b1dd 100755
--- a/test/T400-hooks.sh
+++ b/test/T400-hooks.sh
@@ -28,6 +28,16 @@ EOF
echo "${TOKEN}" > ${2}
}
+create_change_hook () {
+mkdir -p ${HOOK_DIR}
+cat <"${HOOK_DIR}/${1}"
+#!/bin/sh
+notmuch insert --no-hooks < ${2} > /dev/null
+rm -f ${2}
+EOF
+chmod +x "${HOOK_DIR}/${1}"
+}
+
create_failing_hook () {
local HOOK_DIR=${2}
mkdir -p ${HOOK_DIR}
@@ -176,6 +186,17 @@ EOF
NOTMUCH_NEW
test_expect_equal_file write.expected write.output
+test_begin_subtest "pre-new with change in database [${config}]"
+test_subtest_known_broken
+rm -rf ${HOOK_DIR}
+notmuch search '*' > change.expected
+generate_message '[subject]="Inserted"'
+create_change_hook "pre-new" $gen_msg_filename $HOOK_DIR
+generate_message
+NOTMUCH_NEW
+output=$(notmuch search id:$gen_msg_id | notmuch_search_sanitize)
+test_expect_equal "$output" "thread:XXX 2001-01-05 [1/1] Notmuch Test
Suite; pre-new with change in database [${config}] (inbox unread)"
+
rm -rf ${HOOK_DIR}
done
test_done
--
2.31.1.708.gc9a0ac0934
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v2 00/10] ruby: object cleanups
On Tue, May 11 2021, Felipe Contreras wrote: > On Tue, May 4, 2021 at 3:25 AM Felipe Contreras > wrote: >> >> On Tue, May 4, 2021 at 3:17 AM Felipe Contreras >> wrote: >> > >> > This superseeds my previous series [1] with much more cleanups. >> > >> > An important new change is the move towards RTypedData, which is way >> > superior to the old RData >> > objects. >> > >> > Everything should work basically the same though. >> >> Please remove Austin Clements from the CC list, his address doesn't >> work anymore. > > What's the status with these? Shall I split this series of 10 patches > into multiple smaller patch series in order to reduce the reviewing > burden? I would not say it is burden to review the current series; just to find someone capable with time to test it (I personally only use notmuch cli and emacs client, no skills w/ anything else (than "trivial" things)) Tomi > > -- > Felipe Contreras ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Emacs: prevent notmuch from tampering with message headers & settings
As an emacs user, I use notmuch for searching and indexing my mail, and love it. The only problem is that every time I open a message in notmuch, it overwrites my message configuration for sending mails. In particular, it seems to change my headers, and my completion-methods. I need to reset this every time right now. How can I prevent Notmuch from messing with any of these? - Tory ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Possible threading issues in nm 0.32
... just a guess: Could it be that
a9f74aee ("CLI/new: drop the write lock to run the pre-new hook.", 2021-03-18)
was not enough?
notmuch_database_reopen() only reopens the xapian db but does not update
other members in notmuch_database_t *notmuch, such as the last doc id
and thread id.
If a pre-merge hook changes the database then values in that struct will
be out of date.
Before the config changes in nm 0.32, there was no such struct to begin
with. After that, notmuch holds the struct just to be able to run the
hook (from the proper dir).
So I would think that reopen()ing to MODE_READ_ONLY is not a problem.
But after the hook run, are full close() then open() to
MODE_READ_WRITE() is necessary so that the values in the struct are
correct (or change reopen() to do that).
Indeed, if you open in MODE_READ_ONLY and don't hold a write lock you
cannot trust any cached values such as those stored in the struct, can
you?
Michael
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Possible threading issues in nm 0.32
Alexander Adolf venit, vidit, dixit 2021-05-11 16:32:22: > Alexander Adolf writes: > > > Michael J Gruber writes: > > > >> [...] > >> So it seems: > >> > >> - The mis-threading happens during `notmuch new`, not with `notmuch > >> reindex`. > >> - In this new case (and if I remember correctly also in the others), > >> it's always a new message getting worngly put into an existing thread, > >> and if I'm not mistaken, the existing thread was tagged as trash > >> before in all cases. > >> [...] > > > > I can confirm both observations. > > [...] > > p.s.: Just got the weird threading with `notmuch reindex`, too. Oh my gosh... This is getting interesting. I'm delving (literally) into the xapian db now. "Put into an existing thread" (what I had wiritten) was not correct in terms of thread IDs. What's happening is the following: I have an existing message A which is tagged as trash. A is the only message in thread 00021144. A new message B is put in the db by "notmuch new". Notmuch correctly creates a new thread 00021148 (the next avalaible id) and puts B in this new thread. G00021148 is the only thread term in the db for the document belonging to message B. So far so good, but: The document for message A has three thread terms now: G00021144 G00021148 G00021149 Note that neither A nor B have any in-reply-to or references header. AFAIK multiple thread terms on a single message document are a complete no-go and indicate a problem, especially when an unrelated existing message's entry is touched. notmuch search --exclude=false thread:00021148 lists both A and B now, of course. The third one, G00021149, is completely weird. It leads to yet another message document with multiple thread entries. Looking at a few of the most recent messages, my suspicion is: - A new message with in-reply-to/references get's a single (existing) thread term correctly. - A new message without in-reply-to/references get's the correct new thread term; in addition, this get's assigned to some random existing message by *adding* it to the list of terms, thereby making that message part of multiple threads. I have not checked systematically yet whether it (the multi-G-terms) indeed affects Ktrash ones only. Michael ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Possible threading issues in nm 0.32
Michael J Gruber writes: > [...] > So it seems: > > - The mis-threading happens during `notmuch new`, not with `notmuch > reindex`. > - In this new case (and if I remember correctly also in the others), > it's always a new message getting worngly put into an existing thread, > and if I'm not mistaken, the existing thread was tagged as trash > before in all cases. > [...] I can confirm both observations. --alexander ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Is there a reason why the trashed flag is not synced?
On Mon, May 10, 2021 at 03:31:52PM +0200, Michael J Gruber wrote: > Deleting by chance is more harmful, yes. But is it more typical to clear > out duplicate files using "T" or to delete a message (i.e. all it's file > copies)? You have to be a bit careful here... imap is a relatively strange protocol. Consider a provider like gmail that uses a label system over normal imap folders. If you assign a message "inbox" and "vacation" and maybe "archive" and then want to remove the message from inbox and vacation folders you execute delete instructions. That however, certainly shouldn't propagate to the "archive" copy. So I'd argue that in fact no, what you mention is not the "typical" thing to do. At least not with those providers. Not all MUAs behave the same in regards to whether or not they set the trash flag first. Yes, you can tell neomutt to do almost anything, but if setting the Trash flag on one message starts deleting all other copies I'd be very much surprised. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
