Thank you David B. for explanation. I think that everything is clear
now.
David M., what about updating your website on that? I think it's
important to warn about possible files moves between new/ and cur/.
And what I can do is to prepare patches for afew to handle it
appropriately.
--
Amadeu
Amadeusz Żołnowski writes:
> When I have added 'unread' tag the file was still in new/. Only after
> removing 'unread' afterwards the file has been moved to cur/.
The unread tag corresponds to the *absence* of the ,S flag, so if you
don't add unread at notmuch new, tagging it unread later is eff
David Bremner writes:
> If I understand the code correctly, this movement will only happen
> when one of the maildir-flag-equivalent tags is changed. I haven't dug
> ack through the archives, but I think mutt uses presence in new/ as
> some kind of extra unseen state, so people requested not to mo
David Bremner writes:
> Amadeusz Żołnowski writes:
>
>> What's more surprising is that there is a test case in notmuch test
>> suite which test whether after modifing tag of a mail it is moved from
>> new/ to cur/. Yes, it should be moved on any tag modification if I
>> understand correctly. But
Amadeusz Żołnowski writes:
> What's more surprising is that there is a test case in notmuch test
> suite which test whether after modifing tag of a mail it is moved from
> new/ to cur/. Yes, it should be moved on any tag modification if I
> understand correctly. But it seems it does not for my ma
Hi David,
David Mazieres writes:
> Let's just make sure I understand: Your mail starts out like this:
>
> Path: spam/new/nnn.MnnnPnnnQnRn.machine
> Tags: new
>
> Then you run afew, and afew runs
>
> notmuch tag -new +spam
>
> You are saying that that even though maildir.synchroniz
Amadeusz Żołnowski writes:
> Not necessarily. The recommended setup of notmuch for afew is that
> "notmuch new" tags messages with "new" tag only. Then afew processes all
> messages with "new" tag. So if it is a spam, then it gets "new" removed
> and "spam" added. A spam message at any time doesn
Hi David,
dm-list-email-notm...@scs.stanford.edu writes:
> The one thing I'm still unclear on is whether afew is running on the
> client of the server.
It is run as a post-hook, i.e. after "notmuch new", so it's on the
server.
> I guess the other option is that your maildir.synchronize_flags fal
Amadeusz Żołnowski writes:
>> So... based on all the evidence so fare the culprit seems to be that
>> something is moving mail files into your Spam folder on the client.
>> If that rings any bells and solves the problem, great. If not, here
>> is what we need to do to track it down further.
>
>
Hi David,
First of all thank you a lot for support. I am Cc'ing ml because the
last paragraph may be useful hint for other users.
David Mazieres writes:
> So to be clear, you are getting tons of lines that start "[SERVER]
> [notmuch]" and contain the string "Ignoring non-mail file"? Is the
> "
Hi David,
(Resending, because I forgot to Cc mailing list.)
David Mazieres writes:
>> 3. I run muchsync SERVER.
>> 4. When it lasted much longer then initialization I canceled it by
>> single SIGINT (^c).
>
> Interesting. I wish I knew why this was taking much longer than running
> it on the se
David Mazieres writes:
> Initially, when you run "muchsync --init", it copies all the files to
> your maildir, and for each file invokes
> notmuch_message_tags_to_maildir_flag. That changes the name of the
> file, with the result that the sql database and the actual mail
> directory end up out of
So just to follow up a bit. I looked into things a bit further, and
here is what I found with maildir.synchronize_flags set to true.
Initially, when you run "muchsync --init", it copies all the files to
your maildir, and for each file invokes
notmuch_message_tags_to_maildir_flag. That changes th
Amadeusz Żołnowski writes:
> Hi David,
>
> Fist of all thank you for such elaborate answer.
>
> I have missed the paragraph about maildir.synchronize_flags somehow. I
> have it enabled. So this must be source of a problem (?).
I've only ever tested with mailder.synchronize_flags = true, becaus
Hi David,
Fist of all thank you for such elaborate answer.
I have missed the paragraph about maildir.synchronize_flags somehow. I
have it enabled. So this must be source of a problem (?).
Here follows steps I followed:
1. I initialized server locally with muchsync -vv. My mail is stored in
~
Amadeusz Żołnowski writes:
> Hi,
>
> I am testing muchsync-2 and it looks to me that files names across
> machines are different. Moreover when syncing again after
> initialization it seems muchsync is working on something. I have
> canceled this and rerun muchsync. notmuch reported lots of fi
16 matches
Mail list logo
