From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 14776431FC0 for ; Wed, 23 Apr 2014 00:25:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DqV4pF7ed4b for ; Wed, 23 Apr 2014 00:25:51 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id BEBC8431FBF for ; Wed, 23 Apr 2014 00:25:50 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id 10so433444lbg.21 for ; Wed, 23 Apr 2014 00:25:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:from:to:subject:references :in-reply-to:date:message-id:user-agent:content-transfer-encoding; bh=rl7IkXb7kNG9YxdvTR4GX3Gq5yQ5B3EEkLVU7heUdjI=; b=enHgYlaMQj9aqi5dzi6P9cOhGKxd+lqAbCSX704GG0rzAlwhp41WIqTZ531U8nn0IU xhXUvn551Pl9ua8A9lfPHtYwi1NNTTNg1SMGGv269Per0FZnxdipO5o6X4p4QOdG+190 BtS9/2f26JVDw7+MPFL+fn3GqClCWqMSnZgoPnU38x4jFStsgNgudtffatfyHMJ/vQ15 E+KfAjuhhTn/QzgxY2N+rlhllkl3cDc4yqc3JDpmH3A5pjPS/jTtEnpygbiHQhYRLcZU EJt+H7D95aqo/wKJRDR3uINUWu1wxRTYQcKfBF9AxQyTCRTMyEVsGsoZiq7mLBdogztU H0+g== X-Gm-Message-State: ALoCoQl7NZ6hFFRtufMFCLIMs+3daCWatz0GiIxgB6Xvi8kkacyA7jYMmpkG0+3pKKYzG5giiytY X-Received: by 10.112.95.166 with SMTP id dl6mr1168865lbb.19.1398237946930; Wed, 23 Apr 2014 00:25:46 -0700 (PDT) Received: from localhost ([128.39.46.106]) by mx.google.com with ESMTPSA id fa8sm176087lbc.18.2014.04.23.00.25.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Apr 2014 00:25:46 -0700 (PDT) Content-Type: text/plain; charset=UTF-8 From: Gaute Hope To: David Bremner , notmuch Subject: Re: [PATCH] Add configurable changed tag to messages that have been changed on disk References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com> <87wqf2gqig.fsf@ta.scs.stanford.edu> <1397140962-sup-6514@qwerzila> <87wqexnqvb.fsf@ta.scs.stanford.edu> <1397163239-sup-5101@qwerzila> <87d2g9ja0h.fsf@maritornes.cs.unb.ca> In-reply-to: <87d2g9ja0h.fsf@maritornes.cs.unb.ca> Date: Wed, 23 Apr 2014 09:24:40 +0200 Message-Id: <1398237865-sup-624@qwerzila> User-Agent: Sup/git Content-Transfer-Encoding: 8bit X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 07:25:55 -0000 Excerpts from David Bremner's message of 2014-04-23 00:05:02 +0200: > Gaute Hope writes: > > > > > I am talking about syncing tags to a maildir _folder_, not flags. It > > could be implemented as maildir.synchronize is now, but it would be a > > larger feature which could work in a lot of different ways. > > > > So to try and clarify the use case, this could be used to add a tag > "changed" to each message-id that had one or more files > moved/added/deleted on disk. You would then retag that message using > something like the output of notmuch search --output=files so that a set > of tags corresponds to a set of folders containing the message. Is this > correct? I guess the proposed ctime information could be used for this > as well, if it also tracked those non-tag related changes. I guess this > would make it worse for David M's purposes (although presumeably still > better than nothing). Yes, I would not know what has changed, but I would know which messages to check for changes and then decide whether and how to re-tag it. For the opposite case, when a message has been changed locally by a client and I would want to decide whether I need to copy/move/delete the message based on the tags a tag could be added by the application. In response to the issue of cost of this operation: I don't think it will differ much from how 'new' is handled at the moment. One extension perhaps worth considering is to have ctimes on each source file as well as the db entry, but it might be overkill. I still strongly favor an intenal db-tick over ctime - or store both, the application iterating over the 'changed' tag (or messages changed since last time) would have to store the time of last check as well. A whole bunch of stuff could result in this time being inaccurate, especially if these run on different machines. A db-tick or a _good_ ctime solution can as far as I can see solve both David M's (correct me if I am wrong) and my purposes, as well as probably have more use cases in the future. It would even be an interesting direct search: show me everything that changed lately, sorted. As noted before, my use case could also be solved by implementing it in a similar fashion as sync_flags are now, is it possible to hook into this stage in some way? So that it does not need to be included in core notmuch. - gaute