File search APIs trivially fail

[despair86]

apps that assemble a list of its own files fail trivially when installed to a ZVOL, basically anything that uses https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilea and friends

[see below]

[despair86]

Cygwin or MSYS2 /bin/find fail spectacularly: ([/cygdrive]/f is a ZVOL)

despair@DESKTOP-58CIB3E MINGW32 /f
$ find . -name unix
find: failed to read file names from file system at or below ‘.’: No such file or directory

despair@DESKTOP-58CIB3E MINGW32 /f
$ ls -lah
total 7.7G
drwxr-xr-x 72 ricar ricar    0 Dec 13 01:13  .
drwxr-xr-x  1 ricar ricar    0 Aug 11 13:10  ..
-rw-r--r--  1 ricar ricar  628 Dec 17  2017  .gitignore
-rw-r--r--  1 ricar ricar  596 Jun 29 11:50  0460-use-patched-sqlite-for-solaris.patch
-rw-r--r--  1 ricar ricar  663 Sep 20 18:18  0461-use-patched-sqlite-for-solaris-v1.16.1.patch
drwxr-xr-x 13 ricar ricar    0 Mar  5  2020  6cord
drwxr-xr-x  7 ricar ricar    0 Jan 17  2020  age
drwxr-xr-x  8 ricar ricar    0 Oct 29 01:33  Basilisk
-rw-r--r--  1 ricar ricar  47M Oct 13 00:56  basilisk-20201012031926.solaris2.11-i686.tar.xz
drwxr-xr-x 12 ricar ricar    0 Jan 19  2020  BearSSL
...

/bin/grep fails silently and may not search all the way down when called with -r

[lundman]

git works on normal datasets, but I must admit I've not tried it on zvols, so that is interesting. Must be something high up on the volume replies that is not correct.

[despair86]

oh yeah these are the affected datasets

[despair@sun-pc ~]$ zpool status
  pool: data
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(5) for details.
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        data        ONLINE       0     0     0
          c1t0d0    ONLINE       0     0     0

errors: No known data errors

  pool: data2
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(5) for details.
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        data2       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c1t1d0  ONLINE       0     0     0
            c1t2d0  ONLINE       0     0     0

errors: No known data errors

i don't usually mount my root pool on windows cause i can't quite get the NTFS junction points set up to all of the datasets in the pool (rpool/*, /export/home, /export/home/*, etc)

and updating the features is out of the question until ZoL v2 lands

[ghost]

If it's FindFirstFileA failing, couldn't someone write a program that creates files/directories in a dataset and then calls that function? At least then it'd be easier to start debugging.

[lundman]

Yes, that should be easy to write, the best thing to is to trigger the problem, then as quickly as possible, save the debug buffer. Should show if anything is returning error at least.

[DHowett]

The failure in the original issue body is not because of enumerating files, but because git is failing to create a file named com1.c. This is because COM1-COM9 are reserved Win32 device names at any folder depth with any extension on any filesystem.

This does not account for the failures in your followup issues, but this may help you narrow down a reproduction case that does not involve reserved device names.

[DHowett]

More info on this page (search for AUX)

[lundman]

Be amusing if it required zfs to fail it that case based on the name - but yes, could be something there. The new port is close enough for me to test, so I am almost at a point where I can look into these things again.

[despair86]

i....just noticed that 🤦, i forgot cygwin didn't access the file system directly.

in any case grep and find still fail on zvols, and the underlying issue also breaks a lot of other apps (including titles in #307)

[lundman]

Finally got far enough into new port to test this, surprisingly bash from git for windows, can run find and grep just fine. As it is based on msys I expected it to fail too.

Installed cygwin and it also had no issue. I used ntfs.