[mini.bracketed] oldfiles hangs neovim when mounted directory is not available

[ThomasFeher]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md
• I have updated 'mini.nvim' to latest version

Module(s)

bracketed

Description

I have a mounted remote location via NFS (Linux).
Whenever I disconnect Ethernet or Wifi without unmounting, Neovim is not starting anymore.

The issue is the first part of line 1751 in bracketed.lua (function H.oldfile_ensure_initialized) which is executed during startup of Neovim:

    if vim.fn.filereadable(path) == 1 then recency[path] = n - i + 1 end

vim.fn.filereadable() hangs until the connection is reestablished, which is the normal behaviour of NFS mounts, because I have file paths of that remote location in my v:oldfiles.

I know this is not a very common use case, and it is the users fault if the mounted location is not available, but if that leads to infinite hangs although the location is not used by the user, this becomes an annoyance.
Would it be possible to implement an configurable option to simply remove that check? I could try to create a PR for that.

Neovim version

0.10.2

Steps to reproduce

0. mount remote location to /mnt/mymount
1. nvim -nu minimal.lua needs to only load mini.bracketed
2. :e /mnt/mymount/myfile.txt this should add the file path to v:oldfiles
3. :q
4. disconnect network connection without unmounting
5. nvim -nu minimal.lua (this hangs infinitely)

Expected behavior

Neovim should start normally at 5. above.

Actual behavior

Neovim hangs infinitely at 5.

[echasnovski]

Thanks for the issue!

I don't have the means to reproduce this, so I'd have to ask for your help to find the best fix.
Could you, please, try replacing both instances of vim.fn.filereadable(path) == 1 (this and this) with vim.loop.fs_stat(path) ~= nil and see if it fixes the hanging issue?

---

As a side note, I'd also suggest creating an issue in vim/vim repo about this behavior of filereadable(). I don't think it should ever hang.

[ThomasFeher]

Applying the changes as suggested does not fix the issue, it still hangs.

[echasnovski]

Hmm... Then there is either a complete redo of the tracking logic or declaring this as a known limitation. I'll take a closer look to try and reproduce this locally.