fs_event watcher not started for .git folder on Windows

[akriese]

Description

The problem

While starting the plugin for a git repo, it tells me that no fs_event watcher could be started for the .git folder.

The error states the path as C:\Users\anton\Documents\ActivityRadar\backend\.git, where the weird character before the last backslash seems to be the problem.

Tracking it down

I tracked the creation of the path back and found out, that the git command to retrieve the project root returns a newline.

This is of course handled at the end of that function by removing the trainling newline. But my problem lies in having msys2 installed and so the plugin thinks I am a cygwin user (which I am not). In this call the cygpath program does something weird with the trailing whitespace which is not yet removed (namely, producing the weird trailing character).

My thoughts on solutions

One easy thing that would fix the issue (at least as far as I see it), would be to remove the trailing newline directly after the vim.fn.system call. Like so:

-local toplevel = vim.fn.system(cmd)
+local toplevel = vim.fn.system(cmd):gsub("\n", "")

That way it doesnt get screwed up by cygpath.

Another approach would be to try fixing it on the cygpath side. As that use case is very niche, I'd prefer to opt for the first approach. As the one requesting the msys2-support (#1290), @bstaint, could you tell us if you have the same issue currently? :)

Neovim version

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

Operating system and version

Win 11

nvim-tree version

9ef6c3c

Minimal config

-- I'll provide this if necessary

Steps to reproduce

...

Expected behavior

No response

Actual behavior

No response

[dante0624]

I'm also a windows user and I'm seeing the same thing. It only happens when I open nvim tree to a path which has a .git folder.

My exact message reads as:
Could not start the fs_event watcher for path C:\Users\dante\OneDrive\Desktop\Connect_Four_Project\.git : ENOENT.

What is extra strange is that this issue was not happening just a couple weeks ago, but has started now. This may be because of some small change made to NvimTree within the past couple weeks, as Packer is constantly updating all my plugins. I
also am using NVIM v0.9.0 and at the time of posting this I am using the latest version of NvimTree e2a4c9d.

I can try to pull previous version of NvimTree to see which commit may have caused the bug.

[dante0624]

Update: I don't believe that this has anything to do with the version of NvimTree. I noticed that when I remove the plugin ToggleTerm the error went away. Then when I re-added the plugin I had the error again. Clearly something is goes wrong when both plugins are combined, but I am not sure what.

[dante0624]

Slightly closer finding a solution. I realized that the error only occurs if I set vim.opt.shell = "powershell" as opposed to the default on windows which is "cmd.exe". I was doing this in my ToggleTerm configuration, as I was following ToggleTerm's wiki section here. That full wiki sections also changes several other vim options, but the one which causes the error is specifically setting the shell to "powershell"

[akriese]

Hi @dante0624, thanks for the insights! The problem seems to be that powershell does know about the cygpath tool. Can you check whether you have that installed? You can try :echo executable('cygpath') with either shell options set in nvim or Get-Command cygpath in powershell :)

Edit: Additionally, I still think it's a problem of NvimTree if there is an error by setting vim.opt.shell to powershell ;)

[akriese]

I just tested not setting shell to powershell and it seems to work even though the whole cygpath block is still executed.
So, the problem might be vim.fn.system("cygpath..."...) call. Because cmd.exe does kind of ignore newlines (try it in the terminal, you won't be able to insert newlines in a command at all). powershell actually forwards the newline character to cygpath resulting in the weird cygpath output.

[akriese]

I just tried tackling this problem by changing the following:

if has_cygpath then
- toplevel = vim.fn.system("cygpath -w " .. vim.fn.shellescape(toplevel))
+ toplevel = vim.fn.system("cygpath -w " .. vim.fn.shellescape(toplevel:gsub("\n", "")))
  if vim.v.shell_error ~= 0 then
    return nil
  end
end

This doesn't affect the non-powershell+cygpath users and solves the problem with cygpath getting weird input with powershell. @dante0624, can you try this change? If it works, I'll create a PR with the change :)

EDIT: Do you guys think, replacing the newline character is risky? I dont recall paths to be able to include \n but I might be wrong. Otherwise we can just take the sub(0, -2) approach.

[dante0624]

Hi @akriese, I totally think that you are onto something here. First, I ran :echo executable('cygpath') and got back a 1, indicating that I had it. Additionally, after running Get-Command cygpath in powershell I got pack that I had that as well at location C:\Program Files\Git\usr\bin\cygpath.exe. Also yes, I believe that this is a bug within NvimTree so a PR would be very appreciated :)

I also tried that single change you proposed and it fixed it on my end as well. I would trust you to make a PR on this more than me as it seems like you understand it a little better than I do. However, if you do make one I think you are supposed to adhere to clean room replication. We should really do this, because we have a very specific use case where cygpath is enabled and / or powershell is being used.

Thank you!

[alex-courtis]

Thank you all for the detailed investigation.

nvim-tree developers don't have access to nor expertise with windows. We can't make changes however PRs are most gratefully appreciated.

Please ensure that any fixes are behind the appropriate windows feature flag. They are members of utils.lua: is_wsl and is_windows.

Possibly unrelated but maybe useful: we did experience some issues with newline delimited status output. This was resolved by using NUL instead of LF delimiting, see #1783

[dante0624]

@alex-courtis I understand the importance of using the windows flags. I believe that the full change which @akriese was proposing looks like this:

  -- 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))
    +      toplevel = vim.fn.system("cygpath -w " .. vim.fn.shellescape(toplevel:gsub("\n", "")))
      if vim.v.shell_error ~= 0 then
        return nil
      end
    end
    toplevel = toplevel:gsub("/", "\\")
  end

Does this do the same thing? It looks like it is already guarding the change such that it only applies to windows users.

[dante0624]

Also thank you for looking into this for us, even though it is strictly a windows problem. Ik the real solution is just to switch off windows but I'm being stubborn lol

[alex-courtis]

Does this do the same thing? It looks like it is already guarding the change such that it only applies to windows users.

It looks OK; it would be best to test all permutations of configurations e.g. WSL, powershell, cygwin, vim.opt.shell etc.

Ik the real solution is just to switch off windows but I'm being stubborn lol

You'll never look back.