Any git directory will report [NvimTree] Could not start the fs_event watcher for path C:\test_project\.git : ENOENT

[mj2068]

Description

After a few months without updating any plugins, today i did a :PackerUpdate, opened a random git directory, got this warning:
[NvimTree] Could not start the fs_event watcher for path C:\test_project\.git : ENOENT
After some reading, and comparing the logs with a no-issue ubuntu with mostly the same config. i think there is a newline/return issue there.
I don't think i'm skillful enough to dig deeper, I hope the info i provided here is useful, Thanks.

Neovim version

NVIM v0.9.1
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3

Operating system and version

Windows 10

nvim-tree version

4054fc4

Clean room replication

unmodified

Steps to reproduce

1. nvim -nu /tmp/nvt-min.lua C:/any_dir_has_a_.git
2. :NvimTreeOpen
3. console pop up, issue arise:
   [NvimTree]
   Could not start the fs_event watcher for path C:\test_project.git
   : ENOENT

Expected behavior

No response

Actual behavior

nvim-tree.zip

[alex-courtis]

i think there is a newline/return issue there.

A newline issue seems plausible. The multiline message is only shown when there is genuinely a newline.

Unfortunately I don't have access to or expertise with windows.

I'd be most grateful if you could test whether we can actally watch a path with that slash pattern:

Please open the following and :source it, with various combinations of a valid directory/file PATH as well as with some newlines.

fs_event_test.lua.gz

[mj2068]

Ok, @alex-courtis, first of all, thanks for dealing with us "Windows PowerShell/Terminal niche market customers"😛.

I did this on both Ubuntu and Windows, with the a same folder structure like this:
/tmp/test
├── fs_event_test.lua
├── nvt-min.lua
├── project1
│   └── .git
└── project2

I expected and confirmed on ubuntu everything went well, i can give PATH anything, project1, project2, etc. and it will print "success". I can also :NvimTreeOpen, and navigate to any folder, entering them. git tracking also works, untracked file or modified file will have icons before file name.
As to newline characters, if PATH contain either \r or \n, it will fail and print the error message, but i think that is to be expected, because newline characters is not allowed in paths.

Interestingly on Windows, everything worked fine as well, the PATHs i tried all printed "success", which are as follow:
C:/tmp/test
/tmp/test
C:\tmp\test
\tmp\test
It too fails when PATH is given like "C:/tmp/test\r" or "\tmp\test/n", both results printed that "Could not..."message in the fs_event_test.lua script, with a slight difference due do how neovim treats "\r"(display as ^M) and "\n"(actual line change).

The problem here on Windows, occurs when in NvimTree File Explorer windows, navigate to a folder that's git initialized(contain a real .git folder) and hit Enter, red error text message will pop up in the console.

log: nvim-tree_10151730.zip
and i checked the log, it seems that from a certain point(log line 35) the code has received a path with a trailing newline char, which caused subsequent functions to fail.
I then tracked to the source code, and found the line i thought was the source of log line 35, here:
https://github.com/nvim-tree/nvim-tree.lua/blob/aaee4cd896b74f85a81bed7eef2db7869960c4d0/lua/nvim-tree/git/utils.lua#L62C1-L62C1
the function: M.should_show_untracked(cwd) was given that path with a trailing newline char.

that's what I have so far.

[alex-courtis]

This is great, thank you for testing. It seems that we can be flexible around path formats, just not any sort of newline.

I'll take a look at normalising paths on the weekend.

[alex-courtis]

I'd be most grateful if you ran a feature flag audit for your windows powershell, to assist us in dealing with this future issues.

Having feature flags we can confidently query may make resolution faster.

Please open and :source this feature flag enumerator:
has.lua.gz

[mj2068]

feature flags log:
has_list.zip

But, I think I found the problem. Here, line 39 and 43::

nvim-tree.lua/lua/nvim-tree/git/utils.lua

Lines 35 to 50 in aaee4cd

	-- git always returns path with forward slashes
	if vim.fn.has "win32" == 1 then
	-- msys2 git support
	if has_cygpath then
	toplevel = vim.fn.system("cygpath -w " .. vim.fn.shellescape(toplevel))
	if vim.v.shell_error ~= 0 then
	return nil, nil
	end
	git_dir = vim.fn.system("cygpath -w " .. vim.fn.shellescape(git_dir))
	if vim.v.shell_error ~= 0 then
	return nil, nil
	end
	end
	toplevel = toplevel:gsub("/", "\\")
	git_dir = git_dir:gsub("/", "\\")
	end

Updates for toplevel and git_dir. These two lines of vim.fn.system function use cygpath to convert the paths to Windows form, but the return value of vim.fn.system would add a trailing \n char to the paths, causing them to be invalid.

Initially, I thought this is probably a Windows only cygpath quirk that added the \n char. But, then i tried similar thing on Ubuntu, there too, vim.fn.system added trailing \n char, you can try this:

$ nvim -c "lua print(string.byte(vim.fn.system('echo hello'),1,-1))"
output: 104 101 108 108 111 10

notice the trailing 10 for \n char.

The two vim.fn.system calls are inside a if vim.fn.has "win32" == 1 then check, so that's why it only affected Windows.
But if this is the general behavior of vim.fn.system, it could affect Linux somewhere else, right?

Can you confirm this?
Much appreciated <3.

[alex-courtis]

That's fantastic investigation, thank you.

I'd be most grateful if you could submit a PR with that fix. I can try, however we will need to go back and forth to test etc.

[alex-courtis]

Many thanks for the feature flags @mj2068 , it was very enlightening: https://github.com/nvim-tree/nvim-tree.lua/wiki/Development#os-feature-flags