From 3322fac5f0db1ca8421c88b8f48b88f758e3566a Mon Sep 17 00:00:00 2001 From: Jean-Francois Dockes Date: Tue, 18 Nov 2014 08:29:48 +0100 Subject: [PATCH] doc --- website/download.html | 7 +++++-- website/features.html | 12 +++++++----- website/filters/filters.html | 14 ++++++++++++++ website/index.html.en | 14 +++++++++++++- website/release-1.19.html | 35 ++++++++++++++++++++--------------- 5 files changed, 59 insertions(+), 23 deletions(-) diff --git a/website/download.html b/website/download.html index 6c44ba2d..32369fef 100644 --- a/website/download.html +++ b/website/download.html @@ -293,8 +293,11 @@ packages if you want use the source rpms.

Fedora

Recoll is present in the standard Fedora package repositories starting from -F-12. The new versions are tracked quite closely, so I don't build the rpms any -more (email me if you need one).

+ F-12. The new versions are usually tracked quite closely, but + 1.19.14p2 is not there yet, so here are some packages + for Fedora 20 and Fedora + 21. There are only x86_64 binaries for now, use the source rpm + for other archs.

OpenSUSE

diff --git a/website/features.html b/website/features.html index 9d578419..93350ba6 100644 --- a/website/features.html +++ b/website/features.html @@ -160,12 +160,14 @@

The current Recoll version is @@ -94,6 +95,17 @@

+
2014-11-09
If you are still running anything + older than 1.19.14p2, YOU SHOULD + UPGRADE. In + particular, this index + corruption issue leading to repeated reindexing of + documents, and possibly query problems too, can be pretty + ennoying.
+ GOTO download and + install 1.19.14p2 or 1.20. Reset your index after + upgrading (rm -rf ~/.recoll/xapiandb).
+
2014-07-28
A nice new application to complement Recoll: recollfs implements a Fuse filesystem where Recoll queries are diff --git a/website/release-1.19.html b/website/release-1.19.html index fd25f0c5..fef25791 100644 --- a/website/release-1.19.html +++ b/website/release-1.19.html @@ -34,15 +34,17 @@ be turned on only by editing recoll.conf (see the manual). If you do so, you must then reset the index.

-

Always reset the index if you do not know by which version it was created -(you're not sure it's 1.18). The simplest way to do this is to quit all Recoll -programs and just delete the index directory (rm -rf ~/.recoll/xapiandb), then start -recoll or recollindex.
-recollindex -z  will do the same in most, but -not all, cases. It's better to use the rm method, which will also -ensure that no debris from older releases remain (e.g.: old stemming files -which are not used any more).

+

To be safe, always reset the index when upgrading to 1.19. There + was a persistent index corruption issue in 1.18 + and earlier versions. + The simplest way to do this is to quit all Recoll + programs and just delete the index directory ( + rm -rf ~/.recoll/xapiandb), then start + recoll or recollindex.
+ recollindex -z  will do the same in most, but + not all, cases. It's better to use the rm method, which will also + ensure that no debris from older releases remain (e.g.: old stemming files + which are not used any more).

Installing 1.19 over an 1.18 index will force a lot of reindexing anyway because Recoll switched to using st_ctime instead of st_mtime to @@ -74,12 +76,15 @@ Configuration menu.

  • 1.19.14 fixes relatively minor but ennoying issues in indexing, plus a few other glitches:
      -
    • The use of a separate readonly Database object for querying - the index while indexing would trigger Xapian errors, (bad - block reads), and subsequent up-to-date check failures - (leading to unnecessary reindexing). The jury is out as to the - cause, but using the same object for reading and writing seems - to eliminate the problem.
      • +
    • The use of a separate readonly + Database object + for querying the index while indexing would trigger Xapian + errors, (bad block reads), and subsequent up-to-date check + failures (leading to unnecessary reindexing). The jury is out + as to the cause, but using the same object for reading and + writing seems to eliminate the problem. This is linked to + a Xapian + ticket.
    • An unnecessary log message in the child process between forking and executing the filter could block on a mutex, and lead to a 20 mn timeout for the affected father process thread