nautilus search, when several places are choosen only the latest is searched

Bug #275495 reported by braweheart on 2008-09-28
This bug affects 8 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
nautilus (Ubuntu)

Bug Description

Steps to reproduce:

Open a folder
Press CTRL + F and search for something
now you can click a"+"-button to edit place
click "+" again and choose another place
now two different folders are selected, and it looks like the search will be carried out in both of them
search for something that should bring up results from both folders
you will se there is only results only from the last choosen folder

Hardy AMD64

nautilus --version

I've heard of the same behaviour in Intrepid

Bowmore (bowmore) wrote :

I can confirm the same inconsistent behaviour for Nautilus 2.24.0 (Intrepid).

Sebastien Bacher (seb128) wrote :

Thank you for your bug report, that's known upstream, you can read about it on

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: Confirmed → Triaged
Changed in nautilus:
status: Unknown → Confirmed
braweheart (braweheart) wrote :

Thats' like 1000 days old. This is a very obvious bug and looks really bad. Ubuntu is known for it's user friendliness, and when it looks like something will be done and it isn't, it is _not_ user friendly. Therefore I believe it to be worthwhile for the ubuntu team to take a look at this bug.

Search-folders in nautilus may be very useful and be a significant part of the users ubuntu-experience, but this bug must be fixed first.

Changed in hundredpapercuts:
status: New → Confirmed
Changed in hundredpapercuts:
milestone: none → round-8
komputes (komputes) wrote :

I agree with braweheart. The nautilus search tool is really bad at finding documents. What ubuntu needs, for the sake of usability, is a comprehensive advanced search interface with full robustness to search different file attributes clearly. I will attach screenshots of how this looks in songbird when making an advanced playlist. This type of search is needed for the filesystem.

Attached is proof that it will not find documents if it is not in the last "Location" field.

komputes (komputes) wrote :
komputes (komputes) wrote :
antistress (antistress) wrote :

i agree with komputes
see related bug

Changed in hundredpapercuts:
milestone: round-8 → round-10
pt123 (pt123) wrote :

Kompute's proposals are cluttered and not pleasing on the eye.

Nautilus' current search is great for most of your searches. When you have a folder with many files, you press ctrl + F and you are presented with the cursor already in the search textbox and all you need to enter a portion of the name and press enter. Simple and quick.

Unlike Windows XP where you have to answer so many questions before you are even allowed to enter your search text.

Please avoid cluttering the basic search window.

komputes (komputes) wrote :

@pt123 - I agree that it does not go along with the whole "limited GNOME simplicity" thing. It is not meant as a replacement but as an option for advanced searches. As it is today, you cannot make a search to find files over 1GB or files of a certain type (for example) without resorting to the command line. The fact is advanced search has been a user need in GNOME for a while.

To separate this request from this bug which requires a quick fix, I have opened the following brainstorm:

@braweheart @antistress - Please visit this brainstorm link to approve/vote/comment.


OK, the problem is actually worse than I thought. Not in a single place (except for the gui) is the code enabled to handle more than one location, ranging from the NautilusQuery class, the engines to the XML file for saved queries.
This is obviously not a papercut unless we disable the option to add multiple places in the gui (isn't super easy either).


Adding a error dialog when searching multiple locations seems like the easiest (and ugliest) option.

OK, maybe it wasn't *that* hard to fix - I've now got multi location search working. Patch later or tomorrow. Here's a screenshot for proof ;-)

Upstream bugzilla seems to have problem attaching files atm [1] so I'm attaching it here first.

This patch fixes the problem when you've selected multiple search locations and only the last one was search. It changes the NautilusQuery api, the savedSearch file format (compatible with previous format) and updates the simple search.

As I'm not a tracker nor beagle expert I'd like them to update the other engines.

Please give it a try and comment your result.


braweheart (braweheart) wrote :

Wonderful news :-)

To patch stuff is beyond me, but while you'r coding, may I be so bold and make a wish? I would really like to set "depth" for every folder, how many levels of subfolders that will be searched. I'm thinking of a numerical value that you could enter (perhaps a dropdown list) right next to where you choose the folder. This way it would be easy to merge some folders, and you'd get a really smart an easy to use search folder funtionality.

Or should I just make an idea on ubuntu brainstorm instead? Anyway, many thanks for the bugfix, any chance it will get into Karmic?

braweheart, of course you could make a wish ;-). But I do think you should create a separate bug for it (as this bug is for fixing what is broken). Fixing this for the "simple" search engine should be quite easy but I'm not sure how to do it for tracker and beagle (but still not trivial as you need to update the file format, the query api etc etc).

I'd say the chance is low to get it into karmic unless the tracker and beagle people jump in and fix there engines and the nautilus dev are really quick to say they'll commit this after the freeze and the karmic packagers want an extra patch to carry around.... But we can wish :)

Sebastien Bacher (seb128) wrote :

Could you contact the upstream nautilus list to get your patch reviewed? They get too many bugzilla comments to read those but tend to be responsive on the list for reviews

Sebastien, yes I will, I have more patches that needs review so I'll contact them on IRC.

Changed in hundredpapercuts:
assignee: nobody → David Siegel (djsiegel)
assignee: David Siegel (djsiegel) → Canonical Desktop Team (canonical-desktop-team)
milestone: round-10 → r2
status: Confirmed → In Progress
Sebastien Bacher (seb128) wrote :

the upstream bug comment should be read before considering the patch there, upstream explain that criterious work using "and" now, the ui should be modified rather than the logic changed

Vish (vish) on 2010-02-18
Changed in hundredpapercuts:
importance: Undecided → Low
Vish (vish) on 2010-06-11
Changed in hundredpapercuts:
milestone: lucid-round-2 → maverick-round-1-file-management
Changed in hundredpapercuts:
assignee: Canonical Desktop Team (canonical-desktop-team) → nobody
Changed in nautilus (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
Vish (vish) wrote :

No one is actively working on this bug , reverting back to triaged.

Changed in hundredpapercuts:
status: In Progress → Triaged
Changed in nautilus:
importance: Unknown → Medium
Vish (vish) on 2010-11-23
Changed in hundredpapercuts:
milestone: maverick-round-1-file-management → nt4-nautilus
Changed in nautilus:
status: Confirmed → Expired
Sebastien Bacher (seb128) wrote :

the issue should be fixed in 3.5.4

Changed in nautilus (Ubuntu):
status: Triaged → Fix Released
Changed in hundredpapercuts:
milestone: nt4-nautilus → papercuts-nautilus
Changed in hundredpapercuts:
milestone: papercuts-nautilus → papercuts-s-nautilus
Paul White (paulw2u) wrote :

Closing Papercuts task as issue resolved

Changed in hundredpapercuts:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
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.