/usr/bin/locate , maybe OT - but asking anyway

[Richard L. Hamilton]

MacPorts "slocate" would get around that limitation; but it's pretty messed up; doesn't create the "slocate" group, doesn't supply /opt/local/etc/updatedb.conf or /opt/local/etc/mtab. The absence of the latter, even with the former configured to exclude nfs, means it's not usable for me, because right about now, it's hunting through my gazillion nfs mounted files...

> On Jun 20, 2019, at 11:15, Bill Cole <macportsusers-20171215 at billmail.scconsult.com> wrote:
> 
> On 20 Jun 2019, at 8:56, Christoph Kukulies wrote:
> 
>> I’m wondering why the /usr/bin/locate command doesn’t find anything that’s located in ~/Documents, when ~/Documents is located on iCloud Drive.
>> 
>> Trying to locate (even after a /usr/libexec/locate.updatedb) doesn’ t look in iCloud Drive.
> 
> The locate.updatedb script is intended to run as the "nobody" user and so only see parts of the system that are visible to all users. Some versions of that script actively enforce that design by fixing ownership of the locate DB and relaunching as nobody.
> 
> It's a privacy issue. Despite the evolution back towards computers being one-user devices, MacOS is still a multi-user Unix derivative at heart and 'locate' is part of that heritage. If you want to find a document that you own in a directory that only you can access, the "mdfind" utility (which uses Spotlight's DB) will do that.
> 
> -- 
> Bill Cole
> bill at scconsult.com or billcole at apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
>