thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.1 2010-03-09T17:22:29Z 2010-03-09T17:22:29Z Carl Worth cworth@cworth.org 2010-03-09T17:22:29Z urn:sha1:4e5d2f22db290a830c0267f34b519c6138af00ed We rename 'has_more' to 'valid' so that it can function whether iterating in a forward or reverse direction. We also rename 'advance' to 'move_to_next' to setup parallel naming with the proposed functions 'move_to_first', 'move_to_last', and 'move_to_previous'. 2010-01-23T09:45:23Z Carl Worth cworth@cworth.org 2010-01-23T09:45:23Z urn:sha1:c25bc03dc60846090d230cdad21e39faccce35ff How foolish of me to advertise the fact that I pushed a commit without compiling it first... 2010-01-23T05:58:30Z Carl Worth cworth@cworth.org 2010-01-23T05:58:30Z urn:sha1:344c48a47de23cc63f1885d850b82359d1a34064 The fix was subtle, (requiring less code than originally expected), so it behooves us to document it well. 2010-01-23T05:52:30Z Geo Carncross geocar-notmuch@internetconnection.net 2010-01-21T20:10:18Z urn:sha1:c5416b6f1b2ec0ab1bcc011b521542a7839479d2 Such as reiserfs or xfs. This has been broken since the merge of support for rename and deletion of files from the mail store. Here's the original justification for the patch: A review of notmuch-new.c shows three uses of ->d_type: Near line 153, in _entries_resemble_maildir() we can simply allow for DT_UNKNOWN. This would fail if people have MH-style folders which have three folders called "new" "cur" and "tmp", but that seems unlikely, in which case the "tmp" folder would simply not be scanned. Near line 273 in add_files_recursive() we have another check. If DT_UNKNOWN, we fall through, then add_files_recursive() does a stat almost immediately, returning with success if the path isn't a directory. Thus, the fallback is already written. Finally, near line 343, in add_files_recursive() (a long function) we have another check. Here we can simply treat DT_UNKNOWN as DT_LNK, since the logic for the stat() results are the same. 2010-01-10T01:38:23Z Carl Worth cworth@cworth.org 2010-01-10T01:38:23Z urn:sha1:c340c1bd1140c0a1b7e0f24ef3ebac806f5fc3e6 Previously we were printing a number of messages upgraded so far. The original motivation for this was to accurately reflect the fact that there are two passes, (so each message is processed twice and it's not accurate to represent with a single count). But as it turns out, the second pass takes zero time (relatively speaking) so we're still not accounting for it. If nothing else, the percentage-based reporting makes for a cleaner API for the progress_notify function. 2010-01-08T16:45:16Z Carl Worth cworth@cworth.org 2010-01-08T16:45:16Z urn:sha1:c485c51585d8e51d289eb9830203fa322d7a0740 Our signal handler is designed to quickly flush out changes and then exit. But if a database upgrade is in progress when the user interrupts, then we just want to immediately abort. We could do something fancy like add a return value to our progress_notify function to allow it to tell the upgrade process to abort. But it's actually much cleaner and robust to delay the installation of our signal handler so that the default abort happens on SIGINT. 2010-01-08T02:30:32Z Carl Worth cworth@cworth.org 2010-01-08T02:30:32Z urn:sha1:e307e990c9394b6426e55b28c748c265358a1c89 This takes advantage of the recently added library support to detect if the database needs to be upgraded and then automatically performs that upgrade, (with a nice progress report). 2010-01-08T02:20:28Z Carl Worth cworth@cworth.org 2010-01-08T02:20:28Z urn:sha1:21f8fd6967c3ef8e726652bbd6944e29975508b5 Previously, when notmuch detected that a directory had been deleted it was only removing files immediately in that directory. We now correctly recurse to also remove any directories (and files, etc.) within sub-directories, etc. 2010-01-07T18:29:05Z Carl Worth cworth@cworth.org 2010-01-07T18:29:05Z urn:sha1:807aef93d3bf02884f7a37b44b894c11d9e1df58 Previously we had NOTMUCH_DATABASE_MODE_READ_ONLY but NOTMUCH_STATUS_READONLY_DATABASE which was ugly and confusing. Rename the latter to NOTMUCH_STATUS_READ_ONLY_DATABASE for consistency. 2010-01-06T22:35:56Z Carl Worth cworth@cworth.org 2010-01-06T22:35:56Z urn:sha1:1a38cb841ca4ce87f6b57f9b1baf1a5f8b8e35b7 When we know that we are adding a new directory to the database, (and we therefore are using inode rather than strcmp-based sorting of the filenames), then we *never* want to see any names from the database. If we get any names that could only make us inadvertently remove files that we just added. Since it's not obvious from the Xapian documentation whether new terms being added as part of new documents will appear in the in-progress all-terms iteration we are using, (and this might differ based on Xapian backend and also might differ based on how many new directories are added and whether a flush threshold is reached). For all of these reasons, we play it safe and use NULL rather than a real notmuch_filenames_t iterator in this case to avoid any problem.