Chapter 2. Options

The settings for XLocate are stored in your home directory in a file named xlocaterc on Qt3 or xlocate.conf on Qt4.

This file has five sections:

Geometry and layout are remembered accross sessions. Everything else is configurable through the three tabs of the Options dialog box, displayed by clicking on the Options button. of the main application's window.

2.1. The Drives tab

Here you select some or all of your drives as indexable. By giving some extra info about your drive configuration, you can tailor XLocate to your needs and enhance its usability.

Screenshot of Options DB / Drives

The second column (mount point) and the sixth (read-write flag of drive) are set by the operating system.

The first column (index) is a check box where you decide if the drive whose mount point appears in the second column is among those that you'll want to index (using the Update command).

The third column (removable unit flag) must be checked if the concerned drive is designed for removable media (CD-ROMs, USB flash memory sticks, removable disk cartridges, DVDs, floppies, etc.)

The fourth column (excluded subdirectories) is a comma-separated list of the subdirectories of the mount point which you want to exclude from the database. It might be mount points for other file systems you'd like to index separately (e.g. /mnt) or temporary files directories you don't mind to index (e.g. /tmp, or /var/tmp). Note that the paths you specify are considered absolute, so they must always begin with the mount point given in the first column.

The fifth column (name) is just a display name you would like XLocate to use to refer to the drive. You can use any nickname of your choice, provided it does not contain slashes (/) nor spaces (you will still be able to use spaces in the volume names for removable drives). If you leave this field blank, the absolute mount point will be used (with slashes replaced by underscores). Since items are alphabetically sorted in the volumes list according to their nicknames, which are just the filenames of the databases minus extension, you can name the fixed drives (or ln to their DB files) in such a way that they will be listed at the beginning of the list, this way avoiding to swamp the few entries for your local hard disks amidst hundreds of CD-ROMs for example. It is not recommended to give the device name as a display name since in certain configurations the same drive might be assigned different device names between session, which might be confusing.

Note

For fixed drives, the index file name will be the display name with the extension ".ro" (for read-only mounts) or ".rw" (for read-write) added. So the naming restrictions applying for file names apply for display names, with the extra restriction of no space inside fixed drive names.

Note

For removable drives, the index file name used for their volumes (e.g. CDROM, flash memory sticks, removable disk cartridges, etc.) can be anything that refer to the volume, not to the drive of course. It might be its volume label for instance.

The sixth column (read-write flag of drive) is checked in case of a writable drive (e.g. local or remote hard disk, removable cartridge or memory stick, floppy) as opposed to a read-only drive (e.g. CDROM, DVD). Since it is normally pointless to update a database for a readonly volume, XLocate will filter out slocate's warning about the obsolescence of the database file if this box is not checked.

If you selected a soft link to a database file, XLocate will give as argument to slocate the ultimate target of any series of soft links, so the eventual warning you'll get will be pertinent with the actual database file, without regard to the age of the soft links (which is not the case as of slocate version 2.6). Thus you won't loose any of the advantages of XLocate by physically putting some DB files outside /var/lib/xlocate (or whatever DBPATH is), and just leaving soft links in DBPATH.

If you try to reindex a read-only file system under an already existing name, XLocate will inform you that the file already exists, but will not prevent you to update it if you confirm. A better scheme using uuid's to prevent duplicate removable media database files might be proposed in a future release.