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