unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Sebastian Spaeth <Sebastian@SSpaeth.de>
To: Rob Browning <rlb@defaultvalue.org>
Cc: Notmuch developer list <notmuch@notmuchmail.org>
Subject: Re: notmuchsync: handling of the deleted tag
Date: Tue, 21 Sep 2010 11:44:29 +0200	[thread overview]
Message-ID: <87zkvb4eiq.fsf@SSpaeth.de> (raw)
In-Reply-To: <87r5gnomt2.fsf@raven.defaultvalue.org>

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

On 2010-09-21, Rob Browning wrote:
> Conceptually what I'd like for it to do, is reference count -- only mark
> the message deleted if every occurrence (across all maildirs) is marked
> trashed (T).

Right, but that is trickier than might appear at first sight.

I parse those file names which notmuch is giving me (by default for
mails from the last 30 days, as reparsing ALL your mails every time
would be horribly expensive and often unneeded). 

notmuch is only able to give me one file name (+path) per mail id, so
that is what I examine. If that is the one copy that has the mail dir
flag "expired/trashed", I tag the message as "deleted". 

There is little else that notmuchsync can do here. I ask for new
messages and their file path and if they are expired mark it as such. I
have no way of finding out if there are other mails with the same mail
id from notmuch (unless I am very much mistaken). 

Doing reference counting would require me/notmuchsync to parse ALL your
mails by itself and finding out the often horribly mail id from the mail
headers myself... something that notmuchsync does not want to get into.

See the problem? I could do reference counting if notmuch were able to
tell me how many file names/paths are associated with a mail id.


> Though even there I can imagine corner cases: imagine that notmuch
> doesn't initially see all your maildirs -- perhaps because you're using
> a folder filter in offlineimap, and so there are untrashed copies in the
> maildirs it hasn't seen yet.

Right that would be a problem. But I cannot do reference counting unless
notmuch can give me the number of copies it knows about for a given mail
id (and internally it does know all associated file paths, so it would
be a simple API extension a la, "get_all_message_file_paths" or similar,
or a get_number_of_mail_files(mailid) to start with.

> > And what should --revsync do when it finds a mail file that is marked
> > as expired.

What should notmuch do BTW if there are 2 copies and 1 is expired and 1 not?
Mark as "deleted" or not?

> Looks like you got cut off there.

Right, it was 5pm and I left the computer :). I had intented to rant
about the deficiencies of the notmuch 1 document per mail id approach
here, but I don't see a better approach. All that would be useful from
the notmuch side is to get all associated filenames with a mail id.

sebastian

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2010-09-21  9:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87bp7vewa5.fsf@raven.defaultvalue.org>
2010-09-20 15:09 ` notmuchsync: handling of the deleted tag Sebastian Spaeth
2010-09-21  2:25   ` Rob Browning
2010-09-21  9:44     ` Sebastian Spaeth [this message]
2010-09-21 13:15       ` Mike Kelly
2010-09-21 13:30         ` Jameson Rollins
2010-09-22  8:53           ` Sebastian Spaeth
2010-09-22  0:30       ` Rob Browning
2010-09-23  7:30         ` Sebastian Spaeth
2010-09-23  7:32         ` Sebastian Spaeth
2010-09-23  8:01         ` notmuchsync default behavior change (was: notmuchsync: handling of the deleted tag) Sebastian Spaeth
2010-11-12  1:27     ` notmuchsync: handling of the deleted tag Carl Worth
2010-11-12  7:30       ` Sebastian Spaeth
2010-11-12 21:04         ` Dirk Hohndel
2010-11-13  0:52           ` Carl Worth
2010-11-14 22:21             ` Sebastian Spaeth
2010-11-14 22:36               ` Jameson Rollins
2010-11-15  1:23               ` Jeff Richards
2010-11-15  3:03                 ` Jameson Rollins
2010-11-15 15:24                   ` servilio
2010-11-15 16:48                     ` Daniel Kahn Gillmor
2010-11-15  3:01             ` Jameson Rollins
2010-11-15 19:58               ` Carl Worth
2010-11-15 20:16                 ` Daniel Kahn Gillmor
2010-11-12 21:16         ` Carl Worth
2010-11-14 22:30           ` Sebastian Spaeth
2010-11-15 20:01             ` Carl Worth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zkvb4eiq.fsf@SSpaeth.de \
    --to=sebastian@sspaeth.de \
    --cc=notmuch@notmuchmail.org \
    --cc=rlb@defaultvalue.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).