bug: render of folder cointaining OneDrive folder fails on Windows

[kmoschcau]

Did you check the docs and existing issues?

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

Neovim version (nvim -v)

v0.11.0-dev-1335+g3f1d09bc94

Operating system/version

Windows 11 Enterprise 23H2 22631.4602

Describe the bug

In my home folder on Windows on my work machine, there's a OneDrive folder that causes oil to fail to render my home folder. I get this error notification:

Error rendering oil buffer oil:///C/Users/KaiMoschcau/: EINVAL: invalid argument: C:\Users\KaiMoschcau\\OneDrive - blecon GmbH

I have no idea what makes this folder special enough to fail. The folder properties don't look special to me and yazi is able to render my home folder no problem. I can also explore inside that OneDrive folder with oil without problems. This really only occurs when trying to render the OneDrive folder.

Also when I navigate to my Windows home folder from inside my WSL instance, oil is able to render my home folder without problems as well.

What is the severity of this bug?

tolerable (can work around it)

Steps To Reproduce

1. Have a OneDrive setup in your Windows home folder
2. Navigate to your home folder with oil
3. The buffer just shows Error: EINVAL: invalid argument: C:\Users\KaiMoschcau\\OneDrive - blecon GmbH

Expected Behavior

Oil should render the buffer as normal and allow me to move through my home folder.

Directory structure

Here's some yazi output of the folder structure for context. The folder OneDrive - blecon GmbH in the middle column is the selected one.

~
  󰉋 KaiMosc│  Lokale Einstellungen -> C:\Users\KaiMoschca │ 󰉋 Anlagen
   Public │  Music                                       │ 󰉋 Apps
           │  Netzwerkumgebung -> C:\Users\KaiMoschcau\Ap │ 󰉋 Bilder
           │ 󰉋 onecoremsvsmon                              │  Desktop
           │ 󰉋 OneDrive                                    │ 󰉋 Dokumente
           │ 󰉋 OneDrive - blecon GmbH                      │ 󰉋 Microsoft Teams Chat Files
           │ 󰉋 OWASP ZAP                                   │  Videos
           │  Recent -> C:\Users\KaiMoschcau\AppData\Roam │ 󰈔 Kai @ blecon GmbH.url
           │ 󰉋 Saved Games                                 │
[…]

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.

[stevearc]

Unfortunately I have neither OneDrive nor a Windows computer right now. I won't be able to help debug this.

[kmoschcau]

Alright. I did some more digging and found out the following:

• The directory in question shows up with Mode lar-- in PowerShell's Get-ChildItem output
• l stands for ReparsePoint (which could also be symbolic links, but I don't think that's the case here)
• Apparently Windows uses "File System Filters" to read the data in the Reparse Point in order to display the file

[stevearc]

Interesting, so it seems like the issue is that we can't list a directory that is a reparse point? I don't know if those would show up as type "link" or as a normal directory, but perhaps the error happens when we're trying to read the link data.