Bug: network drive issue on Windows

bendajam commented 2 months ago

RTFM Checklist

[X] I have searched exisiting issues / discussions
[x] I have read the Wiki including the Advanced section
[x] I have read man fzf / I am well versed in shell fzf

Operating system

Windows

Shell

PowerShell

Neovim version (`nvim --version`)

v0.10.1

Fzf version (`fzf --version`)

0.55.0

Output of `:lua print(os.getenv('FZF_DEFAULT_OPTS'))`

nil

Is the problem reproducible with `mini.sh`?

[ ] My issue is reproducible with mini.sh
[ ] My issue IS NOT reproducible with mini.sh
[X] I have not tested with mini.sh (not relevant, requires LSP, Windows, etc)

Fzf-lua configuration

require('fzf-lua').setup {
        vim.keymap.set('n', '<leader>sf', require('fzf-lua').files, { desc = 'Fzf Files' }),
        -- You can put your default mappings / updates / etc. in here
        --  All the info you're looking for is in `:help telescope.setup()`
      }

Describe the bug / steps to reproduce

This is a network drive issue.

For work I use a windows machine and I have attached linux network drives. After cding into the network drives and opening nvim in that network directory all fzf searches are executed off my base C:\ directory instead of the attached network drive.

ibhagwan commented 2 months ago

After you change directory into the network drive:

What does := vim.loop.cwd() show?
What does :pwd show?
Can you try :lua require'fzf-lua'.files { cwd = [[Z:\]] } (use the correct network drive, Z is just an example) and post a screenshot of the result (I want to see what the prompt cwd is)?
Any errors/earnings in :messages?

bendajam commented 2 months ago

Shows the network directory I'm supposed to be in
same as 1.

E5108: Error executing lua ...ppData/Local/nvim-data/lazy/fzf-lua/lua/fzf-lua/core.lua:245: Vim:E475: Invalid argument: expected valid directory                                                                                                stack traceback:                                                                                                                [builtin#36]: at 0x7ff9a16a2f80                                                                                         ...ppData/Local/nvim-data/lazy/fzf-lua/lua/fzf-lua/core.lua:245: in function 'files'                                    [string ":lua"]:1: in main chunk

I'm guessing because the network drives are mounted like \\dev8\web\etc and not into a Z:\ folder.

ibhagwan commented 2 months ago

I'm guessing because the network drives are mounted like \dev8\web\etc and not into a Z:\ folder.

Most likely the issue.

What happens if you try (3) with reversed slashes //dev8//web…?

bendajam commented 2 months ago

same error. What part of the code should I be looking at if I want to dig into it.

ibhagwan commented 2 months ago

same error. What part of the code should I be looking at if I want to dig into it.

My guess is the error comes from termopen|jobstart: https://github.com/ibhagwan/fzf-lua/blob/db41613292b88b5306d65caf6ae8996db5498ccb/lua/fzf-lua/fzf.lua#L236-L237

Another test we can do is double the starting slashes, e.g \\\\dev\….

bendajam commented 2 months ago

Doesn't throw the error but it does the same as what default happens when I try to find a file where is looks at the root of the windows machine. I'll need to find out more on how these shares are mounted before I can be more help on figuring out what is going on.

ibhagwan commented 2 months ago

Doesn't throw the error but it does the same as what default happens when I try to find a file where is looks at the root of the windows machine. I'll need to find out more on how these shares are mounted before I can be more help on figuring out what is going on.

It’s possible the existing folder test fails with \\\\ before it gets to termopen, :messages would display a warning if that’s the case.

ibhagwan commented 1 month ago

I found 2 issues, first ended up being unrelated, on *NIX vim.fn.expand treats \ as an escape character therfore it needs to be doubled before calling expand, resolved with https://github.com/ibhagwan/fzf-lua/commit/f39de2d77755e90a7a80989b007f0bf2ca13b0dd.

However, the above doesn't happen on Winodws as the behavior of expand changes per platform which brings us to issue (2): cmd.exe is unable to accept being started with a UNC path as its working directory, try running the below inside the network drive and press enter:

:lua require("fzf-lua").files({previewer=false,actions={["enter"]={fn=function() end,noclose=true}}})

bendajam commented 1 month ago

Didn't have access to the windows machine over the weekend, but I did map the network drive to W: and then executed

:lua require'fzf-lua'.files { cwd = [[W:\]] }

and it worked as expected. However, if I cd into the mapped W: drive and try to use fzf to find a file it will still default to the base windows directory. I'm assume because of what you found.

bendajam commented 1 month ago

And yes I get

CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.

When I execute the above.

ibhagwan commented 1 month ago

And yes I get

CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.

When I execute the above.

Unfortunately there’s no solution for this with cmd.exe, to solve this I will have to run fzf in a powershell instead which may or may not be a lot of effort (cmd nested command escaping was a real hassle).

https://github.com/ibhagwan/fzf-lua/issues/1429#issuecomment-2342334201

bendajam commented 1 month ago

I'm sure. I think this can be closed out if you don't plan on tackling it. If I need to use it on the network drive I can just run the command manually. Not the best but it does work. That or just pull the things I'm working on locally.

Appreciate you looking into it!

ibhagwan commented 1 month ago

I'm sure. I think this can be closed out if you don't plan on tackling it. If I need to use it on the network drive I can just run the command manually. Not the best but it does work. That or just pull the things I'm working on locally.

Appreciate you looking into it!

I’ll give it a shot first, if I can somewhat easily convert the cmd command to powershell (with shell redirect, escaping, etc) there is no harm in doing so.

ibhagwan commented 1 month ago

Alright so I gave this a real go by attempting to run the fzf process inside powershell 5 (not 7 which requires a separate install defeating the purpose of this).

So many issues have to be overcome:

Different escaping scheme, not as easy as it may sound due to nested special chars, check out the shellescape testing to get a glimpse of the complexity
No support for the < operator and required additional scripting to read from a windows names pipe \\.\pipe\…
No support for the && and || operators required for internal action scripting (silent fails, fuzzy zero event, etc)

Nevertheless I was able to semi-hack it only to find her another issue, as per fzf $FZF_DEFAULT_COMMAND is hardcoded to run inside cmd.exe meaning that if you set the variable to fd and run fzf within powershell, fd will be wrapped in cmd and thus run in the home directory instead (same as this issue). While possible to use a pipe instead using fd | fzf this brings out yet another issue of process management (fzf is no longer responsible of killing the command when existing).

Overall I concluded this issue doesn’t justify the complexity and effort required for this (basically rewriting Windows support using powershell).

Doesn’t mean I’ll never do it or possibly come up with another creative solution but for now this issue will be closed.

ibhagwan commented 1 month ago

Btw, as I wanted to solve this in fzf-lua’s side I forgot to mention that I came across a solution from the machine side:

Add the below registry key as type DWORD and set value to 1:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor\DisableUNCCheck

For more info: https://web.archive.org/web/20150312195558/https://support.microsoft.com/en-us/kb/156276

bendajam commented 1 month ago

Thanks for looking into this. I'm very annoyed with the general windows developer experience. Hopefully work will let me switch to a unix box. 🤞

ibhagwan commented 1 month ago

Thanks for looking into this. I'm very annoyed with the general windows developer experience. Hopefully work will let me switch to a unix box. 🤞

I feel you, can’t pay me enough to develop on Windows lol

ibhagwan / fzf-lua