bug: directories mounted on a network filesystem (NFS) have wrong icons

[ibhagwan]

Did you check the docs and existing issues?

• I have read the docs
• I have searched the existing issues

Neovim version (nvim -v)

0.10.3

Operating system/version

NetBSD rie 9.3

Describe the bug

Hi @stevearc,

First let me say ths plugin and your work in general is just amazing, so Ty and Happy New Year 🎉

Not a big issue at all but I searched the issues for "mounted" and "nfs" and couldn't find anything, it seems that when using oil on an NFS mounted file-system the directory icons aren't detected properly.

Without digging into the code my first guess would be bit comparison of the uv.fs_stat return so here's a screenshot of the output from my local filesystem on Linux (left) and an NFS mounted FS on NetBSD (right), note the wrong icons (and missing / postfix) for the lua/after/colors/css directories.

Note type = "directory" at the bottom of the output

What is the severity of this bug?

minor (annoyance)

Steps To Reproduce

Use oil on an NFS mount

Expected Behavior

To see the correct icon for a folder.

Directory structure

/004 󰂺  README.md
/005   after/
/006   colors/
/007   css/
/003   init.lua
/008   lazy-lock.json
/009   lua/
/010   screenshot.png

Repro

-- save as repro.lua
-- run with nvim -u repro.lua
-- DO NOT change the paths
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "runtime", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "--single-branch",
    "https://github.com/folke/lazy.nvim.git",
    lazypath,
  })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  {
        "stevearc/oil.nvim",
        config = function()
            require("oil").setup({
              -- add any needed settings here
            })
        end,
  },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

Did you check the bug with a clean config?

• I have confirmed that the bug reproduces with nvim -u repro.lua using the repro.lua file above.

[ibhagwan]

Btw, if you wanna test this quickly signup for a free shell on sdf.org which is where I experienced this bug.

[stevearc]

Based on the symptoms, it definitely looks like it's detecting the type as something other than "directory". The fs_stat output looks fine. I tried to replicate the issue on sdf but I don't fully understand it and couldn't figure out where or how you set up a NFS mount. I do have a NFS mounted fs at home on my linux machine and it works fine, so there must be something else at work.

Could you try putting a vim.print(entry) in this line?

oil.nvim/lua/oil/adapters/files.lua

Lines 379 to 380 in ba858b6

	for _, entry in ipairs(entries) do
	local cache_entry = cache.create_entry(url, entry.name, entry.type)

I suspect the entry.type we get back from fs_readdir is something other than "directory"

[ibhagwan]

I tried to replicate the issue on sdf but I don't fully understand it and couldn't figure out where or how you set up a NFS mount

You don't need to setup anything, your home folder is already an NFS mount, but now that I think about it you'd need to setup nvim 0.10 there which isn't a small feat at all :-)

Could you try putting a vim.print(entry) in this line?

And this is the uv.fs_stat of after showing a directory type:

[ibhagwan]

It seems the luv implementation on the NetBSD is different (or neovim's interpretation of it?), it doesn't return a type as on my local filesystem.

In any event, this seems like an upstream issue (either libuv or neovim) although you could workaround it by using uv.fs_stat if the type field is missing.

[stevearc]

I put in some logic to call fs_stat if the type is missing. Can you check if that fixes the issue?

[ibhagwan]

Ty @stevearc! 🎉