> 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 > >
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
