Re: [PATCH] Add configurable changed tag to messages that have been changed on disk

[Gaute Hope <eg@gaute.vetsj.com>]

Excerpts from David Bremner's message of 2014-04-23 00:05:02 +0200:
> Gaute Hope <eg@gaute.vetsj.com> 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