Directories not walked recursively in FUSE mounted directories

[jpalus]

Checklist

• I have read through the manual page (man fzf)
• I have searched through the existing issues
• For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of fzf --version

0.52.1 (6432f00)

OS

• Linux
• macOS
• Windows
• Etc.

Shell

• bash
• zsh
• fish

Problem / Steps to reproduce

1. Create test directories and files:

$ mkdir -p test/test mnt
$ touch test/test/test{1,2,3,4,5} test/test6

2. Enter test and try to complete files:

$ cd test
$ stat **<TAB>

3. As expected it shows all files and dirs:

$ stat **
>
  7/7 (0) ───────────
> test6
  test
  test/test5
  test/test2
  test/test1
  test/test3
  test/test4 

5. Mount test to mnt over ssh

$ cd ..
$ sshfs localhost:test mnt

6. Enter mnt and try to complete files:

$ cd mnt
$ stat **<TAB>

Expected result: same as for local filesystem
Actual result: only top level items are listed

$ stat **
>
  2/2 (0) ───────────
> test
  test6 

Now the really weird thing is that for some commands it works fine in both cases ls **<TAB> or cat **<TAB>, but not in others vim **<TAB> or mpv **<TAB.

[junegunn]

Do you have any custom configuration?

env | grep FZF_

print -l ${(ok)functions} | grep _fzf_compgen

[jpalus]

Turns out it's an issue caused by caching mechanism in sshfssee libfuse/sshfs#306 for details.

It started to affect fzf with switch to new fastwalk based walker. It relies on proper d_type returned by getdents syscall (translated to readdir in FUSE). If the type is unexpected bogus one is returned which later fails to meet criteria for recursive walk.

On the other hand previous find based walker, which uses fts_read internally, will call stat for each file with unknown type (DT_UNKNOWN) resulting in recursive walk.

[jpalus]

Also submitted charlievieth/fastwalk#18 to match find's behavior cause ie gvfs FUSE mount does not populate stat in readdir at all.