neo-tree.nvim
neo-tree.nvim copied to clipboard
`file_event_callback: EPERM` error notification after some background filesystem actions
Windows 10, neovim 0.9.0, neo-tree 2.59.0.
In some cases, doing filesystem actions - such as git checkout, deleting directories using a shell command, using explorer, or even deleting nested directories using neo-tree itself, - causes neo-tree to soft-lock. The nvim becomes unresponsive and an endless stream of notifications with the text file_event_callback: EPERM appears. There is no way to break out of the soft-lock other than killing the nvim process.

Sadly, the issue is not easily reproducible, and I can not provide exact steps to get it. Sometimes neo-tree handles background file changes, and sometimes it breaks.
This is a huge issue for me too, I'm glad I'm not the only one! Locks up to the point where have to quit neovim and restart. Seems unpredictable one way or the next. The little bit I've been able to track down about it seems to point to something involving node? I'm not sure. I hope someone has some insight, because I'd love it if there was no issue.
Even after that error, the vim breaks meaning I had to close the whole terminal and open it again.
This happens to me pretty much every time I delete a directory using neotree
update: actually it crashes even if i dont use neotree to delete it, simply rm -rf-ing the directory from a separate terminal window would also crash the running neotree instance
@bartektelec Can you provide additional information like OS, neovim version, etc. and perhaps the exact steps you took to reproduce this please? I have tried for a while but I could not reproduce this error.
@bartektelec Can you provide additional information like OS, neovim version, etc. and perhaps the exact steps you took to reproduce this please? I have tried for a while but I could not reproduce this error.
Sure, Windows 11 Pro 22H2 NVIM v0.9.1 Most recent Neo-tree installed through Lazy Using LazyVIM distro
What I do:
- Open up Neovim in any kind of directory, but for this example let it be an empty dir
- I go
<leader>eto open up Neo-tree - I create two folders pressing
ain Neo-tree - called A and B - I can delete them just fine at any moment, but if I ever unfold one of them in Neo-tree and then delete it the problem occurs
- This can also happen when I press
aon a folded directory, it automatically unfolds, and when I fold it and delete it later it also crashes - If I create a dir in neo-tree and then create a file in it using windows explorer so the neo-tree doesn't unfold then I can delete the directory just fine
When deleting an unfolded / opened directory:
When I open, then close then delete:
@bartektelec, thank you for the reproduction.
Can confirm the same issue.
Windows 10 Pro 22H2. NVIM v0.9.1. neo-tree.nvim 2.70.0.
Steps to reproduce in my case:
- Create an empty directory.
cdinto it.nvim .so thatneo-treeis the buffer I see.- Create a directory
ausingneo-tree. - Create a directory
busingneo-tree. - Create an empty file
foo.txtinadirectory (so it "unfolds") and write it to disk. - Delete
adirectory usingneo-treeOR using!rm -Recurse -Force a. - Bug reproduced.
Looks like this behavior is caused by deleting "unfolded" nodes, either via neo-tree or by other means.
Is reproducible on Windows.
I have tried on my computer with:
Windows Education 22H2 (OS Build 22621.1992)
nvim v0.9.1
neo-tree 3.0.0 (commit 981a43a)
and the following configuration file:
vim.g.mapleader = " "
vim.g.maplocalleader = " "
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
vim.fn.system({
"git",
"clone",
"--filter=blob:none",
"https://github.com/folke/lazy.nvim.git",
"--branch=stable", -- latest stable release
lazypath,
})
end
vim.opt.rtp:prepend(lazypath)
require("lazy").setup({
{
"nvim-neo-tree/neo-tree.nvim",
version = "*",
dependencies = {
"nvim-lua/plenary.nvim",
"nvim-tree/nvim-web-devicons",
"MunifTanjim/nui.nvim",
},
config = function()
require("neo-tree").setup({
close_if_last_window = true,
})
end,
},
})
but the issue does not seem to appear :(. Could you have a look to see if the issue still persists with this configuration, please? @yehorb @bartektelec
https://github.com/nvim-neo-tree/neo-tree.nvim/assets/30724347/6700433b-9eb2-4f09-943b-14c0e8af52c1
Can confirm that overriding the config property with the one you provided fixes the issue.
That's because it overrides the whole LazyVIM's opts record.
I narrowed the issue down to be one of the defaults LazyVIM provides:
use_libuv_file_watcher = true,
This is what causes neovim to crash when deleting a directory, however setting it to false will cause neo-tree not to refresh when I delete the directory using a different file explorer so this can be seen as a temporary fix.
Not sure why libuv would cause it to fail
@bartektelec Thanks for your insights! I'm not sure why using libuv causes this behavior - it is probably some bug between libuv and windows path. I will have a look to see if I could identify the source of the problem, but for now we can turn of the libuv as a temporary fix like you said.
I think the issue is linked to Windows itself. It's always pretty hard to delete files in there. Especially if you'r trying to delete a non-empty folder, or if a file you're trying to delete is open, etc.
@bartektelec Can you provide additional information like OS, neovim version, etc. and perhaps the exact steps you took to reproduce this please? I have tried for a while but I could not reproduce this error.
Try to delete a non-empty folder with a file that is open in the editor inside of it. OS; Windows 11, Version: 0.10, using Powershell to run Neovim.
Windows is the primary reason why this option defaults to false:
https://github.com/nvim-neo-tree/neo-tree.nvim/blob/7e2a3caf999e2028abb643eb0472f351b2777591/lua/neo-tree/defaults.lua#L528-L529
That is the cause of all these errors. If you want to be able to use this feature on Windows, then a Windows user will need to track down those bugs and submit fixes for the file watchers.
Looks like this is the libuv issue indeed. I found fs_stat throwing EPERM issue, there are also a few references to issues in the NodeJS and other projects.
fs_stat is indeed used in nvim-neo-tree file watchers, but I am unable to devise and submit any fixes to neo-tree itself.
For now, Windows users should keep the use_libuv_file_watcher option to false. The default hotkey to refresh the file tree is R.
For lazy.nvim:
return {
{
"nvim-neo-tree/neo-tree.nvim",
opts = {
filesystem = {
use_libuv_file_watcher = false,
},
},
},
}
If you use Neovim distribution that comes with nvim-neo-tree, check if it sets the option to true unconditionally. If so, maybe submit a PR to set it to true only on non-Windows systems.
I don't think this issue should be counted as closed, per se, as the solution of "just don't use the feature on windows" is kind of a bummer, and this person in the issue mentioned seems to think it's a neo-tree issue. https://github.com/libuv/libuv/issues/3267#issuecomment-1804273269
I don't think this issue should be counted as closed, per se, as the solution of "just don't use the feature on windows" is kind of a bummer,
Agreed. I'll re-open, but I'm still waiting on a Windows user to debug and submit a fix.