`Could not start the fs_event watcher for path ... : EPERM`

[luiz00martins]

Description

After starting up nvim-tree with :NvimTreeToggle, and nagivating to a folder which contains a subfolder without access permission, I'll get dozens of error messages such as the one above. Multiple for each failed folder.

Here's a concrete example of the output from :messages when I open nvim-tree in the folder C:\Users\luizh\AppData\Local\:

...
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\msdtadmin : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\Temp\WinSAT : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM
[NvimTree] Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics : EPERM

This is followed by big performance hits over the several minutes/hours of usage:

• Neovim starts slowly chugging more and more ram, over the course of usage (the nvim process got to 8Gb on my machine).
• If it fills up the system's memory, the nvim process clogs to a halt.
• Closing neovim from this state takes some time, possibly because of some cleanup in the background.
• If it was left in that state for too long, even if you :qa, the powershell will just hang trying to close it for minutes, with no end in sight. Only the task manager solves the issue.

Basically, I suspect there's a memory leak involved somewhere.

Neovim version

NVIM v0.9.0-dev-461+ged23cd3e5
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3

Operating system and version

Windows 10

nvim-tree version

a2c7556

Minimal config

local use = require('packer').use

use{"wbthomason/packer.nvim"}

use {
	'kyazdani42/nvim-tree.lua',
	config = function()
		require('nvim-tree').setup {}
	end
}

Steps to reproduce

1. Execute :NvimTreeToggle
2. Navigate to a folder for which the current nvim process does not have permission

Expected behavior

No response

Actual behavior

No response

[luiz00martins]

Note: I didn't post any logs because I have no clue where the nvim-tree logs go on windows. Feel free to probe me on that.

[alex-courtis]

Full disclosure: I'm not a windows user and have no experience with or access to windows.

1. Are these genuine permission failures? Can you access those files? It seems very strange that you cannot access files underneath your home directory.
2. Does this issue occur when you are not using nvim-tree? Please monitor memory usage for the same test cases with and without nvim-tree.
3. Does this issue occur under WSL? powershell has been very problematic in the past and is known to have permission problems.
4. Fix your permissions. Does the issue still occur?
5. Disable watchers. Does the issue still occur?

We have seen this before for specific subdirectories with powershell: #1606 (comment)

We added :help nvim-tree.filesystem_watchers.ignore_dirs to get around this.

Please collect logs. You will receive a startup message telling you the log location.

    log = {
      enable = true,
      truncate = true,
      types = {
        all = false,
        config = false,
        copy_paste = false,
        dev = false,
        diagnostics = false,
        git = true,
        profile = true,
        watcher = true,
      },
    },

[luiz00martins]

See wiki. You'll get a startup message telling you where the log is.

That wiki page is not helpful for windows users. There's no $XDG_CACHE_HOME defined for windows (at least on my machine), so that just left me clueless to where the log files were. I also got no startup message.

Luckly fzf came to the rescue, and it seems that it's under ~\AppData\Local\Temp\nvim\nvim-tree.log.

There's only one line in the log:

[2022-12-12 03:45:55] [watcher] purge_watchers

Note: That's the only one. Even after restarting neovim a couple of times, testing a couple of times, and getting the error a couple of times, that is the only line in the log.

---

Does this issue occur when you are not using nvim-tree? Please monitor memory usage for the same test cases with and without nvim-tree.

No. The memory problems happen directly after, and only after that series of error messages appear. Even if nvim-tree is installed and running, only after the error appears that the memory starts chugging up. This is also very noticeable because neovim takes seconds to close after such event.

Update: I just tested right now, and it actually refused to close for +2 minutes, and just kept chugging more and more
memory in the background (+1Gb), I had to close it under task manager.

---

Are these genuine permission failures? Can you access those files? It seems very strange that you cannot access files underneath your home directory.

Yes, they are genuine permission failures. For example, I cannot delete that folder on windows explorer without opening it as administrator (i.e. the folder genuinely requires admin permission to modify).

That is unusual, but not exactly strange. There may be good reasons for a user to have an admin folder under their home directory (in my case there isn't, it was just a fluke).

---

Fix your permissions. Does the issue still occur?

Nope, only on folders without permission.

However, it's worth noting that I don't think "fix your permissions" is the correct solution. There may be good reasons for a user to have an admin folder... basically anywhere. It's quite unexpected for the program to behave that badly when this is the case.

---

Disable watchers. Does the issue still occur?

No. The problems disappears if I set filesystem_watchers.enable = false.

---

We added :help nvim-tree.filesystem_watchers.ignore_dirs to get around this.

The problem still persists with the following config:

      filesystem_watchers = {
        enable = true,
        debounce_delay = 50,
        ignore_dirs = {'C:\\Users\\luizh\\AppData\\Local\\Local\\ElevatedDiagnostics'},
      },

The plugin still raises the same error for that specific folder. Am I doing something wrong in the config?

[gegoune]

You have duplicated Local in ignore_dirs.

[luiz00martins]

You have duplicated Local in ignore_dirs.

lol, that was silly

---

I've just changed it to:

      filesystem_watchers = {
        enable = true,
        debounce_delay = 50,
        ignore_dirs = {'C:\\Users\\luizh\\AppData\\Local\\ElevatedDiagnostics'},
      },

Interestingly, that does not avoid the error. I still get the error(s) "Could not start the fs_event watcher for path C:\Users\luizh\AppData\Local\ElevatedDiagnostics"

[gegoune]

I haven't got windows machine to test it on but maybe you could try removing escaping backslashes and replace single quotes with double square brackets; [[path]].

[luiz00martins]

      filesystem_watchers = {
        enable = true,
        debounce_delay = 50,
        ignore_dirs = {[[C:\Users\luizh\AppData\Local\ElevatedDiagnostics]]},
      },

Nothing.
(AFAIK, '\\' and [[\]] are equivalent in lua)

[alex-courtis]

See wiki. You'll get a startup message telling you where the log is.

That wiki page is not helpful for windows users. There's no $XDG_CACHE_HOME defined for windows (at least on my machine), so that just left me clueless to where the log files were. I also got no startup message.

Luckly fzf came to the rescue, and it seems that it's under ~\AppData\Local\Temp\nvim\nvim-tree.log.

Updated wiki. I would be most grateful if you could add the cache standard-path location under powershell. You can edit the wiki directly in the browser.

[alex-courtis]

I haven't got windows machine to test it on but maybe you could try removing escaping backslashes and replace single quotes with double square brackets; [[path]].

Confirmed: the backslashes must be escaped as per :help nvim-tree.filesystem_watchers.ignore_dirs :help string-match.

  local expr, pat

  expr = [[/home/alex/1822/x]]
  pat = [[/home/alex/1822/x]]
  log.line("dev", "%d '%s' '%s'", vim.fn.match(expr, pat), expr, pat)

  expr = 'C:\\Users\\luizh\\AppData\\Local\\ElevatedDiagnostics'
  pat = 'C:\\Users\\luizh\\AppData\\Local\\ElevatedDiagnostics'
  log.line("dev", "%d '%s' '%s", vim.fn.match(expr, pat), expr, pat)

  expr = 'C:\\Users\\luizh\\AppData\\Local\\ElevatedDiagnostics'
  pat = 'C:\\\\Users\\\\luizh\\\\AppData\\\\Local\\\\ElevatedDiagnostics'
  log.line("dev", "%d '%s' '%s", vim.fn.match(expr, pat), expr, pat)

  expr = [[C:\\Users\\luizh\\AppData\\Local\\ElevatedDiagnostics]]
  pat = [[C:\\\\Users\\\\luizh\\\\AppData\\\\Local\\\\ElevatedDiagnostics]]
  log.line("dev", "%d '%s' '%s", vim.fn.match(expr, pat), expr, pat)

[2022-12-16 10:54:41] [dev] 0 '/home/alex/1822/x' '/home/alex/1822/x'
[2022-12-16 10:54:41] [dev] -1 'C:\Users\luizh\AppData\Local\ElevatedDiagnostics' 'C:\Users\luizh\AppData\Local\ElevatedDiagnostics
[2022-12-16 10:54:41] [dev] 0 'C:\Users\luizh\AppData\Local\ElevatedDiagnostics' 'C:\\Users\\luizh\\AppData\\Local\\ElevatedDiagnostics
[2022-12-16 10:54:41] [dev] 0 'C:\\Users\\luizh\\AppData\\Local\\ElevatedDiagnostics' 'C:\\\\Users\\\\luizh\\\\AppData\\\\Local\\\\ElevatedDiagnostics

We're escaping once for the lua string and once for the vim pattern.

[alex-courtis]

There's only one line in the log:

Note: That's the only one. Even after restarting neovim a couple of times, testing a couple of times, and getting the error a couple of times, that is the only line in the log.

Logging is known to function under powershell; see #1606 (comment)

The lack of a message at startup indicates that logging may not have started correctly.

Are you certain that you are looking in the correct location and the directory/file permissions are correct? What does :echo stdpath("cache") reveal?

No. The memory problems happen directly after, and only after that series of error messages appear. Even if nvim-tree is installed and running, only after the error appears that the memory starts chugging up.

No. The problems disappears if I set filesystem_watchers.enable = false.

Thank you, this confirms that nvim-tree watchers are a problem.

However, it's worth noting that I don't think "fix your permissions" is the correct solution. There may be good reasons for a user to have an admin folder... basically anywhere. It's quite unexpected for the program to behave that badly when this is the case.

Permissions are problematic under powershell: we do not experience such issues under linux/macOS (and I presume WSL) as nvim and the OS simply don't make directories without permissions available to the user.

The message you are seeing shows that nvim-tree is freeing all the (underlying) resources correctly. There may be a libuv or nvim resource leak however we cannot address that.

[alex-courtis]

@luiz00martins please:

• Double check your logging configuration and attempt to collect logs again; logging with watchers disabled may be necessary.
• Attempt to replicate under WSL: it uses POSIX paths and permissions

Following the results of the above we can take further action.

[alex-courtis]

Ideas:

• Blacklist any watcher failures on a directory for the entirety of the session. This is undesirable for normal use cases as recovery following FS changes is desirable and functional. This should be hidden behind the powershell feature flag.
• Attempt some sort of enumeration of the parent directory before creating a watcher. This would require a developer with access to and expertise with powershell. Once again, hidden behind the powershell feature flag.

Development of the above is difficult and untestable without access to a powershell environment. It would be best if a powershell user completed the above.