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

[VanillaMozilla]

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)]

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.

[Pedro Villavicencio (pedro)]

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

[Pedro Villavicencio (pedro)]

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

[Pedro Villavicencio (pedro)]

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

[VanillaMozilla (vanillamozilla)]

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.

[VanillaMozilla (vanillamozilla)]

Never mind. Done.

[Pedro Villavicencio (pedro)]

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.

[VanillaMozilla (vanillamozilla)]

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)]

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

[VanillaMozilla (vanillamozilla)]

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.

[VanillaMozilla (vanillamozilla)]

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)]

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

[Sebastien Bacher (seb128)]

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

[VanillaMozilla (vanillamozilla)]

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)]

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.