Bug 279351 - Nepomuk strigi filter doesn't filter files sometimes
Summary: Nepomuk strigi filter doesn't filter files sometimes
Status: RESOLVED FIXED
Alias: None
Product: nepomuk
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Chakra Linux
: NOR normal
Target Milestone: ---
Assignee: Sebastian Trueg
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-04 07:23 UTC by Weng Xuetian
Modified: 2011-10-27 18:42 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.7.3
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Weng Xuetian 2011-08-04 07:23:10 UTC
Version:           unspecified (using KDE 4.7.0) 
OS:                Linux

I have some compile file which updated frequently, so I don't want to get them indexed, but the strigi seems some time get it indexed.

Reproducible: Sometimes

Steps to Reproduce:
1. add "build" as a filter
2. compile a large cmake project under "build"

Actual Results:  
no file get indexed under this build folder

Expected Results:  
some file get indexed, some not.

This is quite strange case, maybe because I add filter too late, if I delete those folder, nepomuk doesn't clean it up, so if same folder appears again, it state will still be indexed.

I'm not sure the filter should works on the hole path if the parent folder is in folder the folders/files in it should not be scaned.
Comment 1 Sebastian Trueg 2011-10-27 18:11:59 UTC
Git commit 34cc80cc7682eba487f8868bc1204eecb16a830f by Sebastian Trueg.
Committed on 26/10/2011 at 15:48.
Pushed by trueg into branch 'master'.

Fixed FileIndexerConfig::shouldBeIndexed for exclude filters.

We did not take one issue into account before: imagine we have an
exclude filter "build" and a folder $HOME/x/build/y/. This folder
should not be indexed. This was not handled before.
By checking each component of a path starting from the include folder
this case is now handled, too.

One problem remains: the IndexCleaner does not take this issue into
account yet. This means it will not cleanup all required entries yet.
BUG: 279351

M  +23   -17   services/fileindexer/fileindexerconfig.cpp
M  +2    -3    services/fileindexer/fileindexerconfig.h
M  +35   -0    services/fileindexer/indexcleaner.cpp
M  +63   -3    services/fileindexer/test/fileindexerconfigtest.cpp
M  +1    -0    services/fileindexer/test/fileindexerconfigtest.h

http://commits.kde.org/nepomuk-core/34cc80cc7682eba487f8868bc1204eecb16a830f
Comment 2 Sebastian Trueg 2011-10-27 18:12:19 UTC
Git commit 8f3e7f9efec612ac1dcf2bda3f5e9cb2cfe08b1e by Sebastian Trueg.
Committed on 27/10/2011 at 20:10.
Pushed by trueg into branch 'KDE/4.7'.

Backport from nepomuk-core:

Fixed StrigiServiceConfig::shouldBeIndexed for exclude filters.

We did not take one issue into account before: imagine we have an
exclude filter "build" and a folder $HOME/x/build/y/. This folder
should not be indexed. This was not handled before.
By checking each component of a path starting from the include folder
this case is now handled, too.

One problem remains: the IndexCleaner does not take this issue into
account yet. This means it will not cleanup all required entries yet.

BUG: 279351
FIXED-IN: 4.7.3

M  +34   -0    nepomuk/services/strigi/indexcleaner.cpp
M  +23   -17   nepomuk/services/strigi/strigiserviceconfig.cpp
M  +2    -3    nepomuk/services/strigi/strigiserviceconfig.h

http://commits.kde.org/kde-runtime/8f3e7f9efec612ac1dcf2bda3f5e9cb2cfe08b1e
Comment 3 Sebastian Trueg 2011-10-27 18:42:36 UTC
Git commit b52f5abe47e1a7d9cad9773fc78560e6f83f3e43 by Sebastian Trueg.
Committed on 27/10/2011 at 20:28.
Pushed by trueg into branch 'master'.

Fixed FileIndexerConfig::shouldBeIndexed for exclude filters.

We did not take one issue into account before: imagine we have an
exclude filter "build" and a folder $HOME/x/build/y/. This folder
should not be indexed. This was not handled before.
By checking each component of a path starting from the include folder
this case is now handled, too.

One problem remains: the IndexCleaner does not take this issue into
account yet. This means it will not cleanup all required entries yet.
BUG: 279351

M  +23   -17   nepomuk/services/fileindexer/fileindexerconfig.cpp
M  +2    -3    nepomuk/services/fileindexer/fileindexerconfig.h
M  +35   -0    nepomuk/services/fileindexer/indexcleaner.cpp
M  +63   -3    nepomuk/services/fileindexer/test/fileindexerconfigtest.cpp
M  +1    -0    nepomuk/services/fileindexer/test/fileindexerconfigtest.h

http://commits.kde.org/kde-runtime/b52f5abe47e1a7d9cad9773fc78560e6f83f3e43