On Wed, 10 Nov 2010 00:39:31 +0100, Michal Sojka <sojkam1@fel.cvut.cz> wrote: > Did you try ./maildyr-sync -v? Ah, no. That's always seemed really noisy. What I want is simply to see the information related to a failure *when a failure occurs*, and not a lot of noise, (nor having to re-run with extra options to see the output I want). > test_expect_success is not ideal though. Without -v, it should > automatically show stdout when a test fails. I'll send patch for this in > another mail. Cool. I'll look for that. > This only fails if the message is in */new and there is no */cur. Right. I think that's a little too severe. > I do not know if MH format has something special or it is just plain > files in plain directories. If the latter, the synchronzation should > work unless one of the directories is named 'new'. The MH format is plain files in plain directories. But in this case, I would contend that we don't _want_ the synchronization to work. The files shouldn't be getting renamed at all unless we are dealing with maildir. Neither maildir nor mh give us anything extremely reliable that we can use to unambiguously distinguish between them. But I think a heuristic of: if "cur" and "new" sub-directories exist: then this directory is maildir; And only when this heuristic passes should we be fiddling with filenames in maildir-specified ways. > If you think that what we have now is not sufficient, I'd need some help > with this. I'll look. > P.S. Because of my work on test suite, I didn't do any additional tests > for maildir synchronization, so maybe tomorrow :-( No problem. I appreciate your help improving the test-suite infrastructure! Meanwhile, I ran into one problem with my proposal. We can't use notmuch_message_sync_with_maildir_flags since notmuch_message_sync is an internal interface. The corresponding public interface actually consists of three or four different functions (notmuch_message_add_tag, notmuch_message_remove_tag, and notmuch_message_freeze/thaw). I think it would be quite crazy to add _with_maildir_flags variants of all of those. So maybe we will need a new function for the purpose of synchronizing the current tags of a message to a maildir filename. So that would be, perhaps, notmuch_message_tags_to_maildir_flags or so? Finally, I'm also a bit unsettled about the handling of the "S" flag. For all the other flags it is easy to document that notmuch_database_add_message_with_maildir_flags simply adds the corresponding tag to the message. But we can't say that the presence of the "S" tag prevents this function from adding the "unread" tag, since this function never does add an "unread" tag. Instead, the setting of "unread" is taking place at a higher-level, (inside "notmuch new"). So perhaps the right answer is for the library function to add a "seen" tag, (making the handling of 'T' consistent with all other tags and dropping the "inverse" field from the table). Then, the "notmuch new" program can query the "seen" tag to decide whether it should add its configured new_tags, ("inbox" and "unread" by default). I do want something like that anyway, because I want to make it so that someone that first starts with notmuch and a large collection of maildir messages doesn't end up with every message tagged as "inbox" after their first run of "notmuch new". So anyway, I'm currently working on implementing what I described above. And I may change my mind slightly as I work through things. I'll let you know, -Carl -- carl.d.worth@intel.com