From owner-freebsd-hackers Sun Mar 31 22:00:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA01875 for hackers-outgoing; Sun, 31 Mar 1996 22:00:12 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA01868 for freebsd-hackers; Sun, 31 Mar 1996 22:00:10 -0800 (PST) From: Mike Pritchard Message-Id: <199604010600.WAA01868@freefall.freebsd.org> Subject: locate To: freebsd-hackers Date: Sun, 31 Mar 1996 22:00:10 +4000 (PST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk What do people think of the idea of changing locate & its database update script to keep a list of ALL files on the system, and not just those that can been seen by the world. It always drives me nuts when I use locate to find something I *KNOW* is on my system, but it would not print it because it is in some directory that is mode 750, and not 755, but it is still accessable by my current uid/gid. Locate would then have to be updated to stat each match it finds first before printing it, but I think for most typical locate runs, the performance penalty would be negligble. I know that my typical locate runs usually come up with less than a pageful of matches, and stat'ing each one of those is much better than my running "find / -name xyzzy -print". This also provides the benefit is not listing files which have been removed from the system since the database was updated. Another option is to keep two databases, one of all the public files, as it does now. And a complete database that is accessed with some new option on locate that would verify that the file is accessible to the user before printing it out. Comments?