Nautilus built-in search doesn't work if tracker is disabled

Bug #150379 reported by sengo
40
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
Trunk
In Progress
Wishlist
Ubuntu Desktop Bugs
Nautilus
Fix Released
Undecided
Unassigned
nautilus (Ubuntu)
Fix Released
Wishlist
Ubuntu Desktop Bugs

Bug Description

Binary package hint: nautilus

Nautilus integrated search (CTRL+F) does not return any result without tracker indexes. I don't need an indexing daemon running all the time so I disabled trackerd in "System -> Preferences -> Session" and disabled indexing in "System -> Preferences -> Indexing Preferences".
But, every time I try to search through nautilus, trackerd is spawned automatically and I have no results at all.
Searching through "Places -> Search file" works as usual.
In my opinion nautilus should fall back to the classic (without tracker) search if trackerd is not installed or disabled.

Keep up the good work

Cristian Mammoli

ProblemType: Bug
Architecture: i386
Date: Mon Oct 8 00:32:23 2007
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/bin/nautilus
Package: nautilus 1:2.20.0-0ubuntu6
PackageArchitecture: i386
ProcCmdline: nautilus --no-default-window --sm-client-id default2
ProcCwd: /home/cristian
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
Uname: Linux alastor 2.6.22-13-generic #1 SMP Thu Oct 4 17:18:44 GMT 2007 i686 GNU/Linux

Tags: apport-bug

Related branches

Revision history for this message
sengo (sengo) wrote :
sengo (sengo)
description: updated
Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thanks for your report.

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Wishlist
Revision history for this message
pt123 (pt123) wrote :

Even if Tracker is installed there needs to be an option to let Nautilus not use tracker

If I navigate to a folder and then do a search all I want is results with in the folder.

This is annoying before you could navigate to the /usr/share/icons folder

and search for "contact-new.png" and you will get all the varieties of it in thumbnails.

With this Tracker search you can't expect us to index our root folder.

Also if you search for a general term like you .jpg you will get a zillion results. While with the old search it was specific to a folder.

Revision history for this message
Minsang Kim (minsangkim) wrote :

Not everyone wants to index filesystem, and when disabling tracker should not render Nautilus' search function completely useless.

This should be fixed, back to the old way:
I go to /home/me/music/beatles in nautilus.
I press ctrl+f to search, and type in submarine.
The result should show files with "submarine" in the name, listing a few files in /home/me/music/beatles.

Revision history for this message
Gabriel M. (gabrielm) wrote :

Noticed the same thing, now you can't use nautilus to find files by name anymore.

Instead of an option to disable tracker search in Nautilus, it would be much better to mix search results from tracker and the old search method. Or rather, have tracker index file names, and have an obvious option to search for file name or content when you press ctrl-f. I think the default should be to search for file names in Nautilus.

Revision history for this message
pt123 (pt123) wrote :

There is a some what of a work around,
An application called nautilus-search-tool

http://saettaz.altervista.org/softwa...arch_tool.html

Deb
http://www.getdeb.net/app.php?name=nautilus-search-tool

That lets your right click on folder and search in it. It brings the search dialog found under places, it sets the folder for you so you don't have to browse to it.

But still an option should let you choose what Nautilus search should use.

Revision history for this message
Bruce van der Kooij (brucevdk) wrote :

If you remove the package 'tracker' which includes trackerd (the daemon) when trying to search within Nautilus the following D-Bus error dialog is displayed:

    The folder contents could not be displayed.
    The name org.freedesktop.Tracker was not provided by any .service files.

From what I understand is that if the Tracker daemon is not running it should fallback on a simple 'find' like thing. It also seems this is the way it works in Fedora, though at the moment I cannot verify this.

Revision history for this message
Nick Demou (ndemou) wrote :

I've done a default install of 7.10 some hours before and have the exact same behavior (without configuring anything even vaguely related to indexing )

If I haven't done a thorough search in bugs I would have believed that search doesn't work (just like this user thinks in bug #148701 which is possibly a dupe)

see also bug #81977 which is a possible dupe

Revision history for this message
Nick Demou (ndemou) wrote :

(continuing my previous post) I've verified that in my case the tracker is enabled but apparently it had no time to index all my /home files (copied thousands of them some hours ago). Note also that in my case searches complete almost instantly (<1/2sec)

[I should say that searching for "Desktop" and finding nothing gives a ... bad impression]

Revision history for this message
hualala (baowenle) wrote :

The MOST IMPORTANT search should be searching by file name , not desktop searching.
In 7.10,everytime I search for a file by name,nautilus gives me a lot of file useless whose content (not filename) contains the key word
and I cannot restrict the searching scope
It really annoy me much.

Revision history for this message
Steve K (steve10k) wrote :

My Nautilus installation's search feature was dead as a doorknob. Thanks to this thread, it works again: I uninstalled and purged Tracker, bounced my terminal just to make sure, then reinstalled Tracker and its related packages. Bingo: Nautilus search is working correctly now. I also added a similar comment to Bug 247286 over on Bugzilla - looks like the same problem.

Tracker was running before I started this repair. I imagine something was wrong with a config file somewhere.

Revision history for this message
Steve K (steve10k) wrote :

Nuts. The fix mentioned above only lasted for a few hours - today Nautilus search is dead again. But I do think that my adventure defines the "bug" at hand as a Tracker, not a Nautilus problem.
It may also be useful to know that about the same time these problems started here, the Amarok collection indexer died - it now loops continually, tying up system resources and making the program unusable - may or may not be related.

Revision history for this message
pt123 (pt123) wrote :

What does Wishlist mean in regards to Importance,

I searched the https://help.launchpad.net/FAQ for Importance & Wishlist and could not find anything.

I found bug statuses but it has nothing on 'wishlist'.
 https://help.launchpad.net/BugStatuses

Revision history for this message
goto (gotolaunchpad) wrote :

This is probably caused by bug in libtracker.

tracker_connect return not-null value even if tracker daemon is not installed.
That means, that nautilus will always try to use tracker instead of built-in search.

Revision history for this message
Can Kaya (ckaya) wrote :

A workaround may be found by editing the key "/apps/nautilus/preferences/search_bar_type". Any ideas?

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nautilus - 1:2.21.92svn20080303-0ubuntu2

---------------
nautilus (1:2.21.92svn20080303-0ubuntu2) hardy; urgency=low

  * debian/control.in:
    - don't use tracker since when it's used only the indexed files are listed,
      the search doesn't work when tracker is not running and it's not
      what users expect (lp: #81977, #148701, #150379)

 -- Sebastien Bacher <email address hidden> Wed, 05 Mar 2008 14:59:03 +0100

Changed in nautilus:
status: New → Fix Released
Revision history for this message
pt123 (pt123) wrote :

Great news, Ctrl + F here I come

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

This is some really bad news.
I understand that some people have no need to index their home dirs, but I (and I assume many others) do.
Before this update I used control-F basically all the time to navigate to different parts of my file system (I'm a novelist, and I often forget what my documents are saved as, so I used to search for content). Every search took no more than a few seconds. Now, the search takes a whole lot longer, and I can't even search for content.

From a usability point of view, I find this decision weird. If Ubuntu has chosen tracker to be on by default, I fail to understand why it is not used as default for the nautilus search.

Anyway, could anyone point me in the direction of how to change this, at least for myself?
Thanks.

Revision history for this message
Sebastien Bacher (seb128) wrote :

you have deskbar and the tracker icon easily available you can use for that, nautilus is a filemanager it makes sense to be able to search in a directory for files without depending of what has been indexed yet

Revision history for this message
pt123 (pt123) wrote :

Khashayar Naderehvandi ,
Why don't you assign a key in Gnome like F6 for Tracker? I do something similar for Gnome-Do

Ctrl+F should be for the application itself. In Firefox when I use Ctrl+F it is to search the page I have opened.

Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :

What's the point of having a desktop search feature if you patch the applications not to use it?

Revision history for this message
none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote :

To clarify my last remark, if Tracker is to be really useful, it should be well integrated with the rest of the desktop and not just be an app unto itself.

In my opinion, the real fix for this bug would be to fix whichever issues Tracker may have, not to remove the feature.

As an analogy, if Firefox has a problem loading some https web sites, you'd locate the bug and fix it. You wouldn't claim that the correct bug fix would be to remove https support.

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

I completely agree with Johan, not tying the nautilus search to the search utility provided by the distribution gives a really non-integrated feeling to it all. After all, most users should be searching for files in their home folders, not in /etc (what would they be doing with files outside of home anyway, through nautilus, that they have no permissions for).

The excellent gnome-search utility is a fine frontend for find and grep, I've always used that when I had to find files outside of home.

Also, with regard to pt123's comment, the only way I could limit my (tracker)search to certain folders, was by using the search through nautilus.

One more point is that from a user perspective this is very bad. Say someone migrated from another OS to Gutsy a while back, and became used to the instantness of the nautilus search, as well as how nautilus would find contents of files and so on. After Hardy's release, they would upgrade, and notice that nautilus not only does not find files based on their contents, the search takes a whole lot of time as well.

Since I don't seem to be on my own with regard to this point, should I open another bug?

(In the meanwhile, could some kind soul please tell me how I revert this change locally?)

Revision history for this message
Sebastien Bacher (seb128) wrote :

apparently there is no way to make everybody happy there, reopen the bug if you want but we will not change again this cycle , read the very negative users comments sent there while it was using tracker if you want to know why. You can use the indexer from its panel icon or using deskbar, users expect to be able to look for files in a specific directory using their filemanager what tracker is not able to do yet. the feature could be modified to use tracker too but that's lot of work and the current team doesn't have the ressources to work on those changes

Revision history for this message
Khashayar Naderehvandi (khashayar) wrote :

Sebastien, thanks for pointing out some of those comments.
I'm sure there's a way to settle on a reasonable solution, not necessarily based on the subjective desires of the ones who most easily make themselves heard. But, I understand, any such thing is for the next cycle :-)

However,
>(In the meanwhile, could some kind soul please tell me how I revert this change locally?)
Is this a trade secret? I'm sure it's not a big change, I just can't figure out what it is from the latest source deb (I don't have the previous source deb so I can't see the difference).

Revision history for this message
sengo (sengo) wrote :

Khashayar Naderehvandi, both gnome search tool and tracker do not work with network shares for example. Tracker doesn't work for an external drive which has not been indexed for obvious reason etc. The best solution would be to use tracker if the current directory has been indexed and fall back to the standard old search if not (network share, external drive, tracker disabled).

Revision history for this message
pt123 (pt123) wrote :

If anything it should only be given as a non default option to use a third party application.

As mentioned above Tracker it is not practical to have Tracker index remote folders, (in a work environment you will get in serious trouble if pull this stunt) or your / folder..
Nautilus is a not a simple file manager like Thunar, it can open Network shares, and it would be counter-productive if one couldn't search for a file on a network drive, because of Tracker.

Revision history for this message
Ryan Haigh (ryanhaigh) wrote :

For those like me to impatient to wait for the next release to restore the integrated nautilus search without tracker I have written a howto on recompiling nautilus without tracker support. It can be found on the forums here: http://ubuntuforums.org/showthread.php?p=4524368.

Revision history for this message
Piotr Gawrysiak (pgawrysiak) wrote :

Hmmm, I agree with Khashayar Naderehvandi. Lack of tracker integration in Hardy is basically a regression for me!!! So - is there any way of restoring previous (as per Gutsy) functionality?

Revision history for this message
Ryan Haigh (ryanhaigh) wrote :

You could try having a look at the howto above for recompiling without tracker, check the rules file and see if the packagers have used the same method, if so simply remove --disable-tracker from the configure line. If they have used some other method you may want to look at the configure file in the source to see what the available options are. I believe there may even be an --enable-tracker option.

Revision history for this message
Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount) wrote :

I just marked the project as "fixed", too. That way it does not appear in https://bugs.launchpad.net/nautilus/+bugs?field.status_upstream=pending_bugwatch whcih would be confusing since it is already fixed.

Changed in nautilus:
status: New → Fix Released
Revision history for this message
Mathias Gaunard (loufoque) wrote :

Bug seems to have reappeared in lucid.

Changed in nautilus (Ubuntu):
status: Fix Released → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

don't reopen old bugs if you have a similar issues in a new version, you should open a new bug

Changed in nautilus (Ubuntu):
status: New → Fix Released
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/17201
Submitter: Megh Bhatt (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : A change has been merged

Reviewed: https://review.opencontrail.org/17201
Committed: http://github.org/Juniper/contrail-fabric-utils/commit/8c9de1b99c3e7f57d9ed08b91fecac216abe595f
Submitter: Zuul
Branch: master

commit 8c9de1b99c3e7f57d9ed08b91fecac216abe595f
Author: Megh Bhatt <email address hidden>
Date: Fri Feb 12 14:28:58 2016 -0800

Remove ceilometer pkg list per openstack sku

Ceilometer is supported on all supported openstack sku 3.0 onwards

Change-Id: I2e3beba8d30700d9a79aae977007381ae833cf4d
Partial-Bug: #150379

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.