bug: Error: EBUSY: resource busy or locked: C:\DumpStack.log.tmp

[JohnWilliston]

Did you check the docs and existing issues?

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

Neovim version (nvim -v)

NVIM v0.10.3 Build type: Release LuaJIT 2.1.1713484068

Operating system/version

Windows 11 Pro x64

Describe the bug

I'm increasing seeing this error message when navigating folders using the Oil plugin in Neovim: "Error: EBUSY: resource busy or locked: C:\DumpStack.log.tmp". I'm not sure how to resolve that.

What is the severity of this bug?

minor (annoyance)

Steps To Reproduce

1. I launch Neovim.
2. I do an :Oil . command.
3. I navigate folders. I often find drive roots produce that problem with frequency, though not always. Which is weird.

Incidentally, I was forced to tick that box that says I reproduced the bug with that repro.lua, but whenever I tried launching Neovim like that it just never finished startup. I don't know why.

Expected Behavior

I expected it to navigate folders.

Directory structure

No response

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]

Apologies, but I no longer have a windows machine to even investigate these issues. Windows support is mostly going to be a community effort moving forward

[JohnWilliston]

Fair enough. I don't blame you. I just figured out how to do Lua debugging in Neovim anyway, so maybe I can figure something out. If I do, I'll put together a PR or post or something.

[MarcoBuess]

Turns out that if you disable debug logging it will crash on pagefile.sys. I can't pin down, which change causes this behavior, but that hasn't happened until recently. Is that something that can be reproduced on linux?

[adelarsq]

Is that something that can be reproduced on linux?

@MarcoBuess No. This is something that occurs just on Windows. But I am using it myself and didn't occurs for me.

[MarcoBuess]

Is that something that can be reproduced on linux?

@MarcoBuess No. This is something that occurs just on Windows. But I am using it myself and didn't occurs for me.

Which version/commit are you on @adelarsq if I may ask?

[adelarsq]

@MarcoBuess Of course. I am using the latest version for both Neovim and oil.

I did a search here about this file DumpStack.log.tmp. It's a file that is generated when Windows crashes. So it's not related exactly with oil I think.

I just saw that there is one on my machine, but it's hidden and oil gives no error.

More context on the link

[MarcoBuess]

Yeah it's a crashdump file windows creates which you can disable via registry. Thing is though as I mentioned before it is then crashing on the pagefile.sys which ofc you could disable as well, but this is not generally recommended.

I wonder what is going on because like I mentioned, it was working fine up until very recently. I didn't have the time to pinpoint the commit though.

[adelarsq]

It doesn't make any sense. I have 2 Windows machines with these files (one hidden by permissions rules and another visible) and none shows these errors.

I just got one error like that. But I wasn't even using oil, just editing a file. Maybe some Neovim issue.

[JohnWilliston]

Yeah it's a crashdump file windows creates which you can disable via registry. Thing is though as I mentioned before it is then crashing on the pagefile.sys which ofc you could disable as well, but this is not generally recommended.

I wonder what is going on because like I mentioned, it was working fine up until very recently. I didn't have the time to pinpoint the commit though.

Yeah, I can add with absolute certainty that I previously navigated those directories just fine without Neovim/Oil taking a dump. I wonder if the brainless morons in Redmond shoved some new update I neither need nor want down my throat to "improve" my system yet again.

[MarcoBuess]

@stevearc It seems to be broken since 1f7da07. If I specify commit = "ba858b6" in my lazy spec it is working again. Do you have any hints for me on what I should look for? Thanks.

[JohnWilliston]

Thanks for supplying that, MarcoBuess! I can confirm. I'll take a look at the code changes since and see if I can find a fix. I'm on Windows and have been a developer for a rather long time, though I consider myself a Neovim and Lua newbie.

UPDATE: Interestingly enough, oil.nvim is the first Neovim plugin I can't seem to get working on my local drive. I've always previously been able to clone the repo, point Lazy plugin manager to that directory, and it loads and works just fine. Not this one. Weird. Guess I proved that newbie status just now :/

[MarcoBuess]

I accidentally spammed a couple commits trying to figure out what is going on but looks like I don't get it 😞.

[JohnWilliston]

I can say a few things so far. First, the bug was introduced between commit "ba858b662599eab8ef1cba9ab745afded99cb180" and commit "254bc6635cb3f77e6e9a89155652f368e5535160". And I'm pretty sure the culprit is in how the author changed the handling of entry metadata. I don't quite understand yet what he's doing, but the old M.get_metadata_fetcher function in columns.lua has been done away with in favor of the new fetch_entry_metadata local function in files.lua. There is what seems to me to be a non-trivially different approach to handling links in particular, a call to uv.fs_lstat noticeably added to the files.lua file. But so far I haven't been able to figure out why that's a problem.

My best guess isn't that the code is doing anything wrong, per se, rather that I suspect it's doing more work than it used to do for some items, most notably those that have weird permissions under Windows. I don't have a fix so far. But I feel like I'm getting closer. There just aren't that many differences between that range of commits.

[MarcoBuess]

This is exactly what I suspect too and was trying to figure out by moving some code around. I think it was fetching less info for some files.

[MarcoBuess]

@JohnWilliston It could also be in here:

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

Line 296 in 7041528

local function fetch_entry_metadata(parent_dir, entry, require_stat, cb)

The problem is basically triggered by any uv.fs_stat function that is trying to access a locked file. I haven't figured out yet, how that didn't happen before. 🤯

[JohnWilliston]

Confirmed. I wrote the following helper function to attempt to get the stats for one of the files on which it fails:

function M.fstat_test_1()
    local uv = vim.uv or vim.loop
    local fileName = "C:\\DumpStack.log"
      uv.fs_stat(fileName, function(err, stat)
        if err then
          print("ERROR! " .. err)
      else
          print("Yay! " .. stat)
      end
      end)
end

Every time I execute the function, it gives me the same "EPERM" error. I see the same error from the other files about which Oil complains while navigating folders.

[MarcoBuess]

Between all that higher order function stuff, I can figure out where exactly it explodes. Maybe I will finally have a good reason to setup nvim-dap and run it trough a debugger.

[JohnWilliston]

FWIW, I've got nvim-dap set up and working for both Python and Lua. I just haven't figured out how to debug a plugin running inside Neovim.

[MarcoBuess]

There is the https://github.com/jbyuki/one-small-step-for-vimkind adapter which, from what I understand, runs it in a dedicated nvim session and attaches to that.

EDIT: Here is how LazyVim integrates it: https://lazyvim.github.io/extras/dap/nlua

[MarcoBuess]

Ran through it with a debugger. It dies somewhere here:

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

Line 239 in 7041528

uv.fs_realpath(os_path, function(err, new_os_path)

I still can't figure out whats going on as I can't step into uv.fs_realpath with the debugger.

[JohnWilliston]

Yeah, you shouldn't be able to step into that as I understand it because the uv local variable is being assigned to leverage the Lua bindings for the LivUV library, which I believe is linked as a C lib. You can find the particular documentation for the fs_realpath function here. The Lua debugger is not going to step into that. Unfortunately, that's not much different than the old version that runs fine. It has the same code making the same calls.

[MarcoBuess]

Idk man. Looks like I can't figure it out without a hint in the right direction. 🤷🏻‍♂️

[JohnWilliston]

I'm not giving up yet. I think the key lies in figuring out the differences between that fairly narrow range of commits and maybe the error handling. I don't quite grasp what the author's doing yet with the new metadata management system. It looks like maybe he was changing a previously inefficient way of doing things to a more deferred fetch-when-needed approach or something, and I wonder if perhaps that didn't result in more files being scanned than before.

I don't believe the LibUV library has changed the way it operates, as all my testing shows those same calls that were being made before are giving errors now. So I'm inclined to believe they were giving errors before as well, only he wasn't reporting them and stopping all results as is presently happening. I just haven't had time to dig into it more yet.

Regardless, thanks for the link to help me get the debugger working inside Neovim. I've got to try that.

[MarcoBuess]

What I think is that it doesn't scan more files than before but rather it didn't fetch stats for certain types of files. You can see that previously it doesn't show e.g. sizes and date changed for pagefile.sys so it most likely didn't call fs_stat for these types at all.

I haven't figured out how to stop it from doing that though. When you comment out the file fetching parts it gets stuck in a loading state all together.

[JohnWilliston]

FWIW, I'm not sure "stopping" it from doing the call is a valid approach. I say that because there's really no way to know ahead of time whether it's one of those special files for which the call will fail. I think the better approach is to change the error handling, so that failing on a call to get the fstat information basically marks the file as "I can't mess with this" and then continues on with the next task rather than just outright bailing on everything and putting that big useless error in the middle of the screen.

[stevearc]

Can you give #558 a try and see if it fixes the issue for you?

[MarcoBuess]

@stevearc I'm getting the following:

 Error executing luv callback:
.../AppData/Local/nvim-data/lazy/oil.nvim/lua/oil/log.lua:39: E5560: Vimscript function must not be called in a lua loop callback
stack traceback:
	[C]: in function 'strftime'
	.../AppData/Local/nvim-data/lazy/oil.nvim/lua/oil/log.lua:39: in function 'format'
	.../AppData/Local/nvim-data/lazy/oil.nvim/lua/oil/log.lua:99: in function 'log'
	.../AppData/Local/nvim-data/lazy/oil.nvim/lua/oil/log.lua:117: in function 'warn'
	...Local/nvim-data/lazy/oil.nvim/lua/oil/adapters/files.lua:341: in function <...Local/nvim-data/lazy/oil.nvim/lua/oil/adapters/files.lua:339>

[stevearc]

Ugh...I really wish strftime was on the approved list of vimscript functions to call outside of the main loop. I just removed it, try again?

[MarcoBuess]

Yep, it works now. Thanks for your help ❤️ .

[JohnWilliston]

Oh wow, thank you so much for the fix! I hope some of our ignorant patter back and forth was useful in diagnosing it. I've been enjoying this as a learning experience and will be looking through this version to see if I can appreciate it. It sounds like my comments about the proper approach being different error handling was maybe close to target. Cheers!