Gnome search tool (Search for Files...) fails if searching File System

Bug #506219 reported by VanillaMozilla on 2010-01-12
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Undecided
Unassigned
gnome-utils
New
Medium
gnome-utils (Ubuntu)
Low
Unassigned
Nominated for Lucid by Von
Nominated for Maverick by Von

Bug Description

The Gnome search tool fails to find a newly created file in the home directory, if you search in "File System".

Steps to duplicate:
1. Create a text file 'sqw.txt' in your home directory. (The name is not essential, but simplifies finding the problem.)
2. Places > Computer > Filesystem. Navigate to the file to prove that it is there.
2. Places > Search for Files...
Search in File System. (Ubuntu default ext file system)

Results
1. Displays the message "No files found".

Other information
1. The file is found if you search in the home directory instead of "File System".
2. The file is found after restarting the computer.
3. There is a report ( https://answers.launchpad.net/ubuntu/+question/96802 ) that the file is also found if the "locate" command database is updated.

VanillaMozilla (vanillamozilla) wrote :

I hope gnome-utils is the right package for gnome-search-tool. I spent an hour or two on this with launchpad and Google. This bug was originally (mis?)filed under yelp.

affects: yelp (Ubuntu) → gnome-utils (Ubuntu)
Pedro Villavicencio (pedro) wrote :

Confirmed , it seems it doesn't search anything if you select filesystem. will send upstream.

Changed in gnome-utils (Ubuntu):
importance: Undecided → Low
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
status: New → Confirmed
Pedro Villavicencio (pedro) wrote :

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:
 https://bugzilla.gnome.org/show_bug.cgi?id=606993

Changed in gnome-utils (Ubuntu):
status: Confirmed → Triaged
Pedro Villavicencio (pedro) wrote :

it could be because as you said it's using locatedb for the files there, but that not obvious for end user.

VanillaMozilla (vanillamozilla) wrote :

OK, I've got it, almost. Can someone comment here before I take this back to Gnome? I've already made two small errors in posts over there--once omitting a "not" that makes it look like not a bug--and I don't want to look like a fool and jeopardize this bug. And it is a bug, although I'm afraid someone will declare it a feature.

gconf-editor has a field "quick_search_second_scan_excluded_paths that is supposed to exclude the path from "locate", but it doesn't seem to be working right. By default "/" is excluded. Actually, this excludes all the subdirectories, not just root. But "/etc", "/etc/", and "/etc/*" do not exclude the /etc directory. Is this not an outright bug?

Whatever the syntax, it seems to me that excluding part of the drive by default is (1) contrary to the documentation (unless you count some weasel words in the fine print near the bottom), and (2) unhelpful.

Sorry, I reopened the bug for comments. Feel free to triage it again.

Changed in gnome-utils (Ubuntu):
status: Triaged → New
VanillaMozilla (vanillamozilla) wrote :

Never mind. Done.

Pedro Villavicencio (pedro) wrote :

Please, Do NOT Change the status of a bug if you don't know what you're doing, you can read about bug statuses at https://wiki.ubuntu.com/Bugs/Status ; Thanks.

Changed in gnome-utils (Ubuntu):
status: New → Triaged
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
VanillaMozilla (vanillamozilla) wrote :

I would not ordinarily do that, except that for some reason it appeared to be closed to comments until I changed it. This is no longer the case.

Incidentally, I am always astonished at the slow response of large software systems to bug reports. Here's a major bug (file search fails to find existing files), which should be VERY simple to fix, yet there has been absolutely zero activity on it in 3 months. Perhaps the title isn't the most descriptive, now that we know the cause.

Pedro Villavicencio (pedro) wrote :

You're welcome to submit patches for the issue at the upstream bug tracker for faster review though.

How would I do that? The patch is a simple change of a default value. From comment 3, "quick_search_second_scan_excluded_paths is set by default to / , which excludes the entire disk from the "find" scan." But finding and patching the relevant code is something else.

Actually, I think this might really be a Ubuntu bug. The bug can be fixed with a simple change of defaults. Does that make it Gnome or Ubuntu?

Either way, this really needs to get fixed. Nominating it for "One Hundred Paper Cuts" because it's trivial to fix, but unacceptable that "Find Files..." lies to users.

Sebastien Bacher (seb128) wrote :

Ubuntu is not changing this option in a specific way, it's a GNOME bug

Sebastien Bacher (seb128) wrote :

nomination bug hundredpapercut is not the way to got those fixed either, seems increasing number of users are doing this just because they think it will bring attention to their issue which sort of defeat the purpose of selecting some usuability issue, that one is a normal code bug not an usuability issue

What? Things that don't work don't affect usability? If they don't want bug reports, then they need to be clear about the criteria. I have to say, some of the things that were cited as great paper-cut bugs, and have patches, seem pretty darned trivial.

But on rereading my comments, I see it's not just a choice of default, so maybe or maybe not trivial to fix.

Vish (vish) wrote :

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue, in the default Ubuntu install, that affects many people and is quick and easy to fix. So this bug can't be addressed as part of this project.

- Nice catch , this is an interesting bug but not an intended design flaw, hence not a papercut.
For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.

Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

Changed in hundredpapercuts:
status: New → Invalid
Changed in gnome-utils:
status: Unknown → New
Changed in gnome-utils:
importance: Unknown → Medium
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

Related questions

Remote bug watches

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