Frecency database open fails on proot alpine (termux)

[antozz]

Make sure you have done the following

• I have updated to the latest version of blink.cmp
• I have read the README

Bug Description

On Alpine linux installed in a proot environment under Termux (Android), line 41 of frecency.rs fails like that:

Error executing vim.schedule lua callback: runtime error: Failed to open frecency database: Function not implemented (os error 38)
stack traceback:
        [C]: in function 'init_db'
        ...l/share/nvim/lazy/blink.cmp/lua/blink/cmp/fuzzy/init.lua:12: in function 'init_db'
        ...l/share/nvim/lazy/blink.cmp/lua/blink/cmp/fuzzy/init.lua:43: in function 'fuzzy'
        ...re/nvim/lazy/blink.cmp/lua/blink/cmp/completion/list.lua:111: in function 'fuzzy'
        ...re/nvim/lazy/blink.cmp/lua/blink/cmp/completion/list.lua:86: in function 'show'
        ...re/nvim/lazy/blink.cmp/lua/blink/cmp/completion/init.lua:53: in function <...re/nvim/lazy/blink.cmp/lua/blink/cmp/completion/init.lua:29>

The issue does not seem to affect plain Termux, so may be it is somehow related to musl/alpine.

As a rather dirty (and possibly havoc wreaking) workaround, one can modify frecency.rs by passing in some flags:

let env = unsafe {
            let mut env_builder = EnvOpenOptions::new();
            env_builder.flags(EnvFlags::NO_LOCK | EnvFlags::NO_SYNC | EnvFlags::NO_META_SYNC);
            env_builder.open(db_path).map_err(|err| {
                mlua::Error::RuntimeError(
                    "Failed to open frecency database: ".to_string() + &err.to_string(),

Relevant configuration

No response

neovim version

NVIM v0.10.3 Build type: MinSizeRel LuaJIT 2.1.1723681758

blink.cmp version: branch, tag, or commit

v0.8.2

[Saghen]

Alpine termux, now I've seen everything :D Generally those flags should be safe since simultaneous writes should be next to impossible, but I've put plenty of warnings around it regardless. fuzzy.use_unsafe_no_lock = true

[antozz]

Thanks!

Alpine termux, now I've seen everything :D

I needed something that never dared to execute 32 bit instructions on a 64 only arm :'(