[Nepomuk] Review Request: Watch fixes for symlinks and fiters

[Vishesh Handa]

> On Dec. 3, 2012, 5:06 p.m., Vishesh Handa wrote:
> > services/filewatch/nepomukfilewatch.cpp, line 84
> > <http://git.reviewboard.kde.org/r/107080/diff/1/?file=92573#file92573line84>
> >
> >     How come this doesn't work?
> 
> Simeon Bird wrote:
>     Because what is called from _k_addWatches is KInotify::Private::addWatch, and this over-rides KInotify::addWatch instead.

Ship this part.


> On Dec. 3, 2012, 5:06 p.m., Vishesh Handa wrote:
> > services/fileindexer/fileindexerconfig.cpp, line 186
> > <http://git.reviewboard.kde.org/r/107080/diff/1/?file=92572#file92572line186>
> >
> >     I'm not sure about this. Suppose a user has set "DirA" to be indexed. And that contains a system link to "B".
> >     
> >     
> >     A
> >     A/DirA
> >     A/DirA/linkToB
> >     A/DirB
> >     B/
> >     
> >     Then shouldn't all the files and folders in B get indexed as well?
> >     
> >     I'm not sure how we would handle that in the IndexCleaner.
> 
> Simeon Bird wrote:
>     The intention in this code is that B *should* indeed be indexed as well: shouldFolderBeIndexed checks the list of folders to be indexed. If B is on that list, it has already been indexed, and should not be indexed again. 
>     Otherwise, it shouldFolderBeIndexed will return false, and it will be indexed. 
>     
>     I considered also just dereferencing B always at this point, but I was worried that this would confuse the database, as it could have A/DirA/linkToB stored, and wouldn't know what to do if an event arrived for B/. You seem to suggest in http://community.kde.org/Projects/Nepomuk/SystemLinkHandling though that it is the other way around, that it stores B/ and could be confused if an event arrives for A/DirA/linkToB.

Do not ship this. I'm still thinking about this.


- Vishesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107080/#review22940
-----------------------------------------------------------


On Nov. 10, 2012, 12:30 a.m., Simeon Bird wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107080/
> -----------------------------------------------------------
> 
> (Updated Nov. 10, 2012, 12:30 a.m.)
> 
> 
> Review request for Nepomuk, Vishesh Handa and Sebastian Trueg.
> 
> 
> Description
> -------
> 
> Some fixes for filtering, and some symlink handling (this is patch 2).
> 
> 1. Do not watch symlinks when their target is already watched (by being in the hash of watched paths).
> 
> This does not stop all double-watching of symlinks,
> because the watch on the symlink may be installed before
> the watch on the target.
> 
> However, it prevents infinite recursion if someone has done this:
> 
> mkdir ~/test
> cd test
> ln -s ../ test
> 
> which is nice. 
> 
> 2. Do not re-index symlinks to folders that are already indexed under
> another name. This just saves some CPU cycles and double-counting of results in dolphin search.
> 
> 3. Do not watch folders in the filter exclude list. By
>  default this affects only CMakeFiles and auto4mte (as agreed with Vishesh earlier)
> 
> 4. Do not override addWatch in IgnoringKInotify. This was intended to avoid watching folders on
> the exclude list, but did not really work, and is implemented better by 3. 
> 
> 
> This addresses bugs 208602 and 306342.
>     http://bugs.kde.org/show_bug.cgi?id=208602
>     http://bugs.kde.org/show_bug.cgi?id=306342
> 
> 
> Diffs
> -----
> 
>   services/fileindexer/fileindexerconfig.cpp 5226a79 
>   services/filewatch/nepomukfilewatch.cpp dbe2f82 
> 
> Diff: http://git.reviewboard.kde.org/r/107080/diff/
> 
> 
> Testing
> -------
> 
> Compiled, checked that the cases listed are watched or not watched correctly. 
> 
> 
> Thanks,
> 
> Simeon Bird
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121206/60aa6e3a/attachment.html>