updatedb: not always making slocate find all files.
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Give some more info. Does "foo" always be there, or is a temporary file that could be not present the time updatedb works?
Is updatedb really executed everyday? For instance on a dc server I have that runs slack 12.0 updatedb is executed at about 4 am each day. So your system must be running at the time it is scheduled.
Take a look at updatedb.conf (if you haven't already). Could the directory containing the file be in PRUNEPATHS list?
I haven't studied slocate that much, but I think I've read that it locates files based on user access. Maybe your user doesn't have read permission for that file?
Take a look at updatedb.conf (if you haven't already). Could the directory containing the file be in PRUNEPATHS list?
I haven't studied slocate that much, but I think I've read that it locates files based on user access. Maybe your user doesn't have read permission for that file?
Or PRUNEFS, for that matter ... for all we know it (foo) might be
an external HDD using NTFS ...
Take a look at updatedb.conf (if you haven't already). Could the directory containing the file be in PRUNEPATHS list?
I haven't studied slocate that much, but I think I've read that it locates files based on user access. Maybe your user doesn't have read permission for that file?
From here, I infer the strings PRUNEFS and PRUNEPATHS are variable names. However slocate and updatedb manuals call them options [?!]. Assuming they are environment variables, they are unset or empty, as the set command reveals.
And definitely, in this case, it is not a matter of access rights because, as you can see in post #1, the second invocation of slocate brings 'foo' out.
Quote:
Originally Posted by Tinkster
Or PRUNEFS, for that matter ... for all we know it (foo) might be
an external HDD using NTFS ...
Again, never mind the drive location or file system: second invocation works fine. But, in case my logic is faulty, here are some data (NOTE: usb-in-a-nutshell.pdf is here old foo in post #1):
(a) Only one user account in the system besides root: semoi. Slocate run as, and manual invocation of updatedb made as root (BUT WHO IS the user executing the script /etc/cron.daily/slocate?).
bash-3.1# mount
[..............] (brackets are mine).
/dev/hda1 on /xp type vfat (rw,uid=1000,gid=100)
/dev/hdb2 on /sma type vfat (rw)
bash-3.1#
It's been a long time since I touched /etc/fstab the last time.
(c) After last automatic execution of update (cron.daily) but before manual execution (see post #1), everything in /sma got located by slocate but, as to /xp, only files in the first two levels of the /xp tree had their names printed. E.g.,
Code:
$ locate DIGITA
/xp/DIGITALES III
# locate nutshell
#
AFAIK the cron job runs as the user whose crontab contains it. No matter, slocate takes the privilleges of the user that invoked it (slocate, not updatedb) and searches for files that the user has read access. But this doesn't seem to be the case... I assume the uid of semoi is 1000 ?
... No matter, slocate takes the privilleges of the user that invoked it (slocate, not updatedb) and searches for files that the user has read access. But this doesn't seem to be the case...
I understand. For the file in question, group 'users' has read access granted as well as all other groups:
/dev/hda1, mounted on /xp, is FAT32. In this file system there is no provision for files access rights or ownership. After linux mounts it, all files are seen this way:
Code:
drwxr-xr-x 2 root root 2048 2003-11-04 16:20 z
I, usually being semoi, and many times inside the GUI, find it uncomfortable to write files to /xp, all its subdirs being owned by root. This is why I used options uid=, gid= in fstab. With fstab thus modified, all files in /xp look as owned by semoi to the O.S.
This having been said, the fact mentioned in post #6, point (c), about slocate only finding files in the first and second level of the /xp hierarchy, I find it very hard to understand. Ought something in my linux box, besides slocate's behavior, not be wrong? Thanks for your answer.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.