• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Ubuntu & File searching

R

Robor

Elite Member
This is something that's been bothering me for a while. Sometimes when I'm reading FAQ's and HowTo's I'll come across something that will say something like, "edit your userContent.css file...". Well, say I don't know where that file is located? My first thought is to do a search so I do a search for userContent.css and start the search in 'Filesystem' and it comes up with nothing. However, if I search from 'Home' rather than 'Filesystem' it finds it.

Correct me if I'm wrong but wouldn't 'Filesystem' include 'Home'? I've tried with and without the 'Show hidden and backup files' option as well. Both ways it's the same.
 
In Ubuntu... From the Applications/Places/Systems menu bar... 'Places' then 'Search for Files'
 
Originally posted by: Nothinman
I always use slocate or locate (command-line) to find files on a Linux system.
Click to expand...

That only works if the database is up to date, they're not realtime tools.
Click to expand...

Can you elaborate on that? And does that explanation apply to the GUI searcher in Ubuntu?
 
slocate and locate work by referring to an index of files on the volume. It doesn't actually search the file system for file, but rather looks for the entry in a database, which I would guess has the file's inode number and then displays the file's location.

However, creating a new file on the file system, or some similar activity, does not automatically add this file and its location to the database.

The database has to be updated to find the new file. The command updatedb updates this database.
 
Generally you'll have updatedb already cron'ed to run at 2 AM or some other nightly time. If you want to force a find separate from the 'locate' command you can use 'find', but the syntax is more complex.

find /path/to/search/root -name "*pattern*" -print

So to find all files on the system named 'joe'

find / -name joe -print

You can execute commands based on hits, use fancy pattern matching, et c. If you know that you're looking for a config file and don't want to wait for updatedb to finish, then you might try

find /etc -name filename.i.want.conf -print
 
Thanks scottws & cker. That makes sense.

I still don't understand why the file searcher in Ubuntu finds a file if I tell it to look in my Home directory but if I select File System (which I would think includes my Home dir) it doesn't. 😕
 
I have no idea how the search function that you are talking about in Ubuntu works. Sorry, can't help you there.
 
How long do you wait? It can take a long time to work over a whole filesystem and /home might not be one of the first things checked. Maybe Gnome is being all semantic on your ass and defining "Home Directory" as a seperate entity from the "File System" (which is evil and scary and should only be touched by "experts" :shocked:!!)

Edit: I'm not making fun of you there. I'm poking fun at Gnome's tendency to cater to the completely computer illiterate.
 
It finished and returned with 'no files found' and honestly it couldn't possibly have scanned much. It was over in a matter of 5 seconds. I know earlier when I posted this it took longer to scan and the weird thing is it took the same or longer to scan when I tried from 'home'. Maybe this GUI search is broken?

A 'find' from the command line as stated by cker takes *much* longer to scan the entire drive than the GUI find in Gnome. Using the command line search it found the file. The odd thing is I just did the search from the GUI and it didn't find the same file it found earlier in either 'file system' or 'home'. Weird. I guess I'll just use the command line to search instead.

Edit: Update... I just got this error from find from the command line. "find: WARNING: Hard link count is wrong for /proc: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched."
 
Well I finally found the tool you're talking about, it's gnome-search-tool, and I can verify that it does what you say. What it seems to do is look for the file with locate and then if that doesn't return anything it uses normal find, that's why it seems faster than a normal find. But for some reason, when you search "File System" it never falls back to find.
 
Originally posted by: Nothinman
Well I finally found the tool you're talking about, it's gnome-search-tool, and I can verify that it does what you say. What it seems to do is look for the file with locate and then if that doesn't return anything it uses normal find, that's why it seems faster than a normal find. But for some reason, when you search "File System" it never falls back to find.
Click to expand...

Ah, glad it's not just me then. Thanks for proving that I'm not crazy and/or an idiot! 😀

When I first installed Ubuntu my system I used Automatix. I just ran it and I don't see the gnome-search-tool as an option. I guess that's not where it came from. I've been doing a bunch of reading on tweaks and customizations from other Ubuntu users. I guess I installed it and just don't remember. I didn't even realize it wasn't installed by default.
 
On Debian gnome-search-tool comes in the gnome-utils package. And I would really recommend not using Automatix, if you haven't seen the threads between the Automatix author and LordHunter317 on the Ubuntu forums search around and read them.
 
Originally posted by: scottws
slocate and locate work by referring to an index of files on the volume. It doesn't actually search the file system for file, but rather looks for the entry in a database, which I would guess has the file's inode number and then displays the file's location.

However, creating a new file on the file system, or some similar activity, does not automatically add this file and its location to the database.

The database has to be updated to find the new file. The command updatedb updates this database.
Click to expand...

I just used slocate -u 🙂
 
Do we know the gui search isn't beagle underneath? That would explain the quickness. And I haven't heard much about it lately but maybe it's still buggy...
 
No, it doesn't use beagle. I don't even have beagle installed. That and I just downloaded the source and verified, it only does locate and find.
 
Originally posted by: Nothinman
No, it doesn't use beagle. I don't even have beagle installed. That and I just downloaded the source and verified, it only does locate and find.
Click to expand...

I'm confused. If it's doing a 'find' why does the GUI not find files while the command line command does?
 
I'm confused. If it's doing a 'find' why does the GUI not find files while the command line command does?
Click to expand...

Go back and reread my post from "02/07/2006 11:34 PM", for some reason it doesn't fall back to find if you search "File System".
 
Originally posted by: Nothinman
I'm confused. If it's doing a 'find' why does the GUI not find files while the command line command does?
Click to expand...

Go back and reread my post from "02/07/2006 11:34 PM", for some reason it doesn't fall back to find if you search "File System".
Click to expand...

Ah, thanks for that explanation. So either search specific folders (not filesystem) with the GUI or just stick with the command line find tool.
 
Ah, thanks for that explanation. So either search specific folders (not filesystem) with the GUI or just stick with the command line find tool.
Click to expand...

For now, I haven't looked at the code to see why it does that so it might just be a bug.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top