[locate] database update

[martinengelke]

Package source

Github

App logs

macOS

Current Behavior

it's not updating the locate database

Expected Behavior

should update the locate database

Anything else?

change
lambda: runTerminal("sudo updatedb")
into
lambda: runTerminal("/usr/libexec/locate.updatedb")

workaround:
sudo ln -s /usr/libexec/locate.updatedb /usr/local/bin/updatedb

[ManuelSchneid3r]

We should probably rather remove the update action. Locate comes in several flavors (at least bsd and Gnu) and therefore is hard to make to work on all platforms. That's also why I added the param forwarding. For macos spotlights search could also be an alternative.

[martinengelke]

the original one does not scan your ~/Library because its running as 'nobody' if you run it with sudo (therefore you have to cd / first). It's for safety purpose, so that 'nobody' can't see the user folder specific contents.

Anyway you did a good job with the Albert integration already which is quite smooth and fast since it also stands upon a own indexing database as far as I can see.

[ManuelSchneid3r]

It's an in memory trie. But the performance is not as expected because building (joining) the paths for scoring is expensive. It roughly translates to one microsecond per path. So queries with around 50k items introduce a noticeable delay. It's also not as memory efficient as a sql database. That's all just for performance of having the files (you really need) at hand. However user obv want to index millions of files and complain about speed and memory.

[martinengelke]

That's why I wanted to give locate a try.
I didn't manage to get the standard updatedb working for my ~/Library directory. It can just 'see' the Root Folder and since it's running as 'nobody' it can not detect User specific files:

As a user:

~$ /usr/libexec/locate.updatedb
/usr/libexec/locate.updatedb: line 133: /var/db/locate.database: Permission denied
~$ cd /
/$ /usr/libexec/locate.updatedb
/usr/libexec/locate.updatedb: line 133: /var/db/locate.database: Permission denied

With sudo:

/$ cd ~
~$ sudo /usr/libexec/locate.updatedb
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
~$ cd /
/$ sudo /usr/libexec/locate.updatedb

Did finally the job, as expected, but wasn't scanning the User Folder, since it's 'nobody', as defined in "/usr/libexec/locate.updatedb" and is not the user since its executed from within root / folder

So I tried to route it like the man-page suggests:

/$ cd ~
~$ /usr/libexec/locate.updatedb -U $HOME
/usr/libexec/locate.updatedb: line 133: /var/db/locate.database: Permission denied
~$ cd /
/$ /usr/libexec/locate.updatedb -U $HOME
/usr/libexec/locate.updatedb: line 133: /var/db/locate.database: Permission denied
/$ cd ~
~$ sudo /usr/libexec/locate.updatedb -U $HOME
Password:
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied
~$ cd /
/$ sudo /usr/libexec/locate.updatedb -U $HOME

And since I expected the last line could work (at least it didn't throw an error) it was not indexing anything.

regarding
man locate

BUGS
The locate program may fail to list some files that are present, or may list files that have been removed from the system. This is because locate only reports files that are present in the database, which
is typically only regenerated once a week by the /System/Library/LaunchDaemons/com.apple.locate.plist job. Use find(1) to locate files that are of a more transitory nature.
The locate database is typically built by user “nobody” and the locate.updatedb(8) utility skips directories which are not readable for user “nobody”, group “nobody”, or world. For example, if your HOME
directory is not world-readable, none of your files are in the database.
The locate database is not byte order independent. It is not possible to share the databases between machines with different byte order. The current locate implementation understands databases in host
byte order or network byte order if both architectures use the same integer size. So on a FreeBSD/i386 machine (little endian), you can read a locate database which was built on SunOS/sparc machine (big
endian, net).
The locate utility does not recognize multibyte characters.

Therefore I got coreutils and fnutils via homebrew and did it with 'gupdatedb' and 'glocate' (gnu) instead, which you could even alias to the locate command. But you then also have to add:
export LOCATE_PATH="$HOME/user_glocate.db"
to your .zshrc and .bashrc ...
if you are using
gupdatedb --localpaths='$HOME' --output='$HOME/user_glocate.db'
or add
-d $HOME/user_glocate.db
as an arguments every time running the aliased glocate cmd in albert

I even tried to replace the /var/db/locate.database with my user_glocate.db but its a different format ;/
Thats all a bit tricky and not user friendly, so I gave up for now :/