LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   updatedb/slocate/locate and files > 2GB (http://www.linuxquestions.org/questions/slackware-14/updatedb-slocate-locate-and-files-2gb-4175423514/)

Woodsman 08-22-2012 08:19 PM

updatedb/slocate/locate and files > 2GB
 
Running the updatedb command without the -l0 option results in the locate command not listing files >2GB.

The updatedb man page:

-l <num> Security level. -l 0 turns security checks off, which will make searches faster. -l 1 turns security checks on. This is the default.

What security checks?

What is the presumed relationship between security checks and file sizes?

T3slider 08-23-2012 01:44 PM

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".

Woodsman 08-23-2012 03:23 PM

Slackware 13.1, slocate 3.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.

Woodsman 08-24-2012 01:41 PM

The files being owned by root:root is not the problem. I tested changing ownership and locate still did not list files >2GB.

brobr 08-24-2012 02:45 PM

Post #4 of jamesf in thread "slack64 - v13.37 , error opening eclipse? possible bug in $PATH for jre" might belong here. It says:


Quote:

This link discusses the problem in 2004 https://bugzilla.redhat.com/show_bug.cgi?id=105950

Claimed to be fixed (with certain compile flags?) in slocate-2.7-8

Woodsman 08-24-2012 04:09 PM

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.

T3slider 08-24-2012 06:06 PM

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.

Woodsman 08-24-2012 08:22 PM

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.

mancha 08-25-2012 12:43 PM

It appears you are running up against EOVERFLOW on your 32-bit platforms.

Can you please test the patch I put together (-p0 in slocate source tree)?

-mancha

Woodsman 08-25-2012 01:16 PM

Thanks!

I tested the patch in Slackware 13.1 32-bit. When run as root, the following results in a segmentation fault error:

updatedb -c /etc/updatedb.conf
updatedb -l1 -c /etc/updatedb.conf

The following does not result in a segmentation fault and correctly lists the >2GB files, but the same command worked previously in the unpatched version:

updatedb -l0 -c /etc/updatedb.conf

mancha 08-25-2012 04:43 PM

1 Attachment(s)
Aha, I see the issue. Please try attached patch and add -D_LARGEFILE64_SOURCE to the build flags. If you use a SlackBuild just put it inside the definition of SLKCFLAGS for your arch.

-mancha

Woodsman 08-25-2012 05:34 PM

The latest patch and build flag seems to work well.

I tested the following:

updatedb -c /etc/updatedb.conf
updatedb -l1 -c /etc/updatedb.conf (the default)
updatedb -l0 -c /etc/updatedb.conf

I also deleted and rebuilt the database and the results again were good.

Good job! Thank you!

I will inform Pat.

Didier Spaier 09-01-2012 03:02 AM

In Changelog announcing RC4 I saw:
Code:

a/slocate-3.1-i486-4.txz: Rebuilt.
      Patched to use lstat64 and -D_LARGEFILE64_SOURCE. Thanks to Mancha+.

I did updatedb and could locate slackware-dvd.iso.

Congrats all, this thread can be marked as solved I guess.

Woodsman 09-01-2012 01:45 PM

Yes, I tagged the thread as solved. Pat also backported the patches to previous Slackware releases too. Not bad for a Dead Head. :)

mancha 09-01-2012 05:39 PM

Glad I could help.

-mancha


All times are GMT -5. The time now is 02:06 AM.