Bug 708381

Summary:	Files in moved directory don't show up in search results
Product:	[Fedora] Fedora	Reporter:	Alexandre Oberlin <alxobr>
Component:	mlocate	Assignee:	Miloslav Trmač <mitr>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	14	CC:	mitr
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-06-01 18:26:42 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Alexandre Oberlin 2011-05-27 14:15:36 UTC

Description of problem:
If a directory has been moved since last database update, the files contained in that directory don't show up at all in mlocate searches, with or without the "-existing/-e" option.

Version-Release number of selected component (if applicable):
0.23.1

How reproducible:
readily

Steps to Reproduce:
[alex@Eucalyptus%works]$ mkdir mlocate_testdir
[alex@Eucalyptus%works]$ echo coucou > mlocate_testdir/mlocate_testfile.txt
[alex@Eucalyptus%works]$ ls mlocate_testdir/
total 4
-rw-rw-r-- 1 alex alex 7 May 27 15:29 mlocate_testfile.txt
-- update database --
[alex@Eucalyptus%works]$ locate -e mlocate_testdir
/home/alex/works/mlocate_testdir
/home/alex/works/mlocate_testdir/mlocate_testfile.txt
[alex@Eucalyptus%works]$ locate mlocate_testdir
/home/alex/works/mlocate_testdir
/home/alex/works/mlocate_testdir/mlocate_testfile.txt
[alex@Eucalyptus%works]$ locate -e mlocate_testfile
/home/alex/works/mlocate_testdir/mlocate_testfile.txt
[alex@Eucalyptus%works]$ locate mlocate_testfile
/home/alex/works/mlocate_testdir/mlocate_testfile.txt
[alex@Eucalyptus%works]$ mv mlocate_testdir/ ..
[alex@Eucalyptus%works]$ locate -e mlocate_testdir
[alex@Eucalyptus%works]$ locate mlocate_testdir
/home/alex/works/mlocate_testdir
[alex@Eucalyptus%works]$ locate -e mlocate_testfile
[alex@Eucalyptus%works]$ locate mlocate_testfile
[alex@Eucalyptus%works]$ 
  
Actual results:
Without "--existing/-e" option, moved directory is found but file contained in moved directory is not found, though it is in database, whatever. The results are correct for the directory but not for the file it contains.

Expected results:
Both moved directory and contained file should be found when "--existing/-e" option is not set. Neither moved directory nor contained file should be found when "--existing/-e" option is set.

Additional info:
I did not specifically check for this behavior under gnu locate and slocate, but I never noticed it.

Comment 1 Miloslav Trmač 2011-06-01 18:26:42 UTC

Thanks for your report.

In reporting results of the search, mlocate is not limited only by the -e option, but, for databases created with --require-visibility yes, also by file permissions: there is a single database for all files, but mlocate only shows you the files that you would have been able to find anyway (e.g. unprivileged users can't see any files under /root).

This permission check is performed at the time you run locate, based on the file permissions at that time.  So (locate mlocate_testfile) needs to check the permissions of:
- /
- /home
- /home/alex
- /home/alex/works
- /home/alex/works/mlocate_testdir

before it can conclude that you have the required permissions to find mlocate_testfile.txt .  When mlocate_testdir does not exist, locate can not check its permissions and therefore it does not show the file.

(On the other hand, (locate mlocate_testdir) does show the test directory even if it does not exist any more, because the "works" directory exists and it is readable, so you would have been able to find mlocate_testdir if it still existed.)

The system database is built using the implicit value "--require-visibility yes", therefore locate only shows the files in existing directories.  Using (updatedb --require-visibility no) you can create a database that does not have this behavior, but the system default needs to stay secure.