GNOME Bugzilla – Bug 153569
no results unless "show more options" expanded (symlinked directory)
Last modified: 2009-08-15 18:40:50 UTC
When trying to search for a file-name, gsearchtool doesn't return any results unless the additional options are shown (no other options are enabled, it is enough to klick on the "show more options"-handle to expand the dialog) Example: Serach for "image.zip" Path: "/opt/openoffice1.9.54", additional options collapsed -> no results same with additional options expanded: Name: "images.zip", Path: "/opt/openoffice1.9.54", Size, type... etc on console: $ locate images.zip /usr/opt/openoffice1.9.54/share/config/images.zip $ I guess that gsearchtool uses locate when the options are collapsed and find when the options are expanded (-> nowhere documented, see other bug 153562) /opt is symlinked to /usr/opt and this seems to make the search fail. If bug 153563 will be implemented (don't have to restric this on user's home), this only remains a minor problem, user can klick "update" and the results of the find command will be shown. If not, the user won't get the results. It is anything but obvious that the same search produces different results depending whether some parts of the dialog are shown or hidden. Gsearchtool should not bee to restrictive in parsing the results in this case. (e.g. return the results if the whole path is included in the result of the locate command, not only if result starts with path - maybe check whether first part of search-path is a link and resolve that) (version is 2.8.0 but since that coice isn't offered, I picked 2.6.x)
There is a gconf key /apps/gnome-search-tool/disable_quick_search to prevent this behavior, but that key will also disable the /apps/gnome-search-tool/force_quick_search functionality. Gnome-search-tool is using the locate command to perform the search. It will also use the locate command if the more options section is expanded but no options are selected. It will use the find command to perform the search if the more options section is expanded and options are selected.
This whole issue of when to use the locate or find command needs to be rethought. By default, gnome-search-tool will use the locate command when the following conditions are satisfied: 1) User performs a simple filename search (i.e. no additional options). 2) The search path is _not_ contained within one of the following paths: ${HOME}, /mnt, /media, /proc, /dev, /var, or /tmp What if the hard coded paths where moved to a gconf key? This would allow advanced users to tune gnome-search-tool to their specific needs without making the interface unnecessarily complex for average users.
Your points are true, but how does this explain the different results of a search with expanded options compared to a search with collapsed options (in both cases, the gconf-keys and the directories are the same) compare the screenshots. (again, the locatedb is up-to-date, $ locate images.zip /usr/opt/openoffice1.9.54/share/config/images.zip $ ) Somewhere the results get handled differently. Either there is too much complexity and something "hacky" is going on, or the dialog already behaves as desired (by me -> bug #153563): use of locate if options collapsed, use of find when options expanded (if this is the case, the difference in behaviour should be documented -> bug #153562) $ locate images.zip /usr/opt/openoffice1.9.54/share/config/images.zip $ find /opt/openoffice1.9.54/ -name images.zip /opt/openoffice1.9.54/share/config/images.zip $ (remember /opt is a symlink to /usr/opt) Nevertheless it should return the same results, no matter whether find or locate is used (this bug here) I don't see what more information you need (status NEEDMOREINFO). Please tell me or reopen this one.
Created attachment 32453 [details] search with options collapsed got no results when options collapsed
Created attachment 32454 [details] search with expanded (but unused) options got results when options are expanded.
The results are different because when you have the contains text constraint selected when the search options are expanded. If you removed the constraint then the results would be the same. I will fix this behaivor.
2004-10-15 Dennis Cranston <dennis_cranston at yahoo com> * gsearchtool-support.c: (compare_regex): Fix a potential crash (although it has never been reported). * gsearchtool.c: (build_search_command): Fix logic to correctly determine if an additional option is selected. Fixes part of bug #153569 (Comments 3-6).
>The results are different because when you have the contains text constraint >selected when the search options are expanded. I should have typed... The results are different because you have the contains text constraint selected when the search options are expanded. Fix commited to CVS.
The remaining parts of this bug are a duplicate of 153563.
*** This bug has been marked as a duplicate of 153563 ***
I reopen this bug because it is *not* a duplicate. THIS issue is about /gsearchtool returning different results/ depending on whether locate or find are used. You may say it is specific to my setup (/opt is symlinked to /usr/opt) and close it wontfix or something, but it definitely is not a duplicate of bug #153563.
Do not reopen this bug. A fix for this issue is already in CVS. Thank you for your cooperation.