SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
What version of Slackware are you using? slocate finds files > 2GB just fine for me in 13.37, by default and when explicitly passing "-l 0" or "-l 1". Does your user have access to these files? I think slocate filters out results that the user is not able to access...but I can't think of another reason why security checks would impact the ability to find large files (and indeed it doesn't here). On my system updatedb is just run from the cron script, which does not pass an "-l #" argument and thus defaults to "-l 1".
I am aware the locate command filters files a user does not have access. Based upon your response, I presume that is the implied security checks. Yet the files in question are world readable by all users and can be listed in a terminal or file manager. The files are owned root:root and I wonder whether that is causing the problem.
Thank you. I ran across old discussions about the problem, all claiming to have been resolved. Hence, I did not mention those discussions.
I changed to the root account and ran the locate command. The >2GB files still did not list, further evidence the problem is not ownership.
t3slider is using the same version of slocate and not experiencing the problem, although he is using 13.37 and I'm using 13.1. The 13.37 and 13.1 configure and make portions of the Slackware build scripts are identical with no special patches for either. I don't know what is different between 13.37 and 13.1, or, his system and mine.
Using updatedb -l0 resolves the problem, but I don't know why -l1 breaks >2GB files.
I just tested this on my server running 13.1 and it finds files >2GB there as well, as it should. Both boxes are running 64-bit Slackware. My desktop uses ext4 on a LUKS-encrypted LVM while my server uses xfs on an LVM on a couple of RAID1 arrays. I don't have any 32-bit boxes to test (perhaps there is an issue with the 32-bit slocate...I have no idea). I don't know if deleting the database (/var/lib/slocate/slocate.db) and re-running updatedb would make a difference or not but it may be worth a shot.
Ah --- we found the difference. Thank you. I tested on 13.1, 13.37 and R14 RC2, both 32-bit and 64-bit.
The problem exists on all three 32-bit systems and the three 64-bit systems are okay.
Now to find a cure that does not include forcibly using the -l0 option.
Edit: The problem is with the indexing and not the searching. The database contains strings referencing the >2GB files. Using the -l0 option indicates the problem is the indexing too. That is, the database is not changing but only the display results.