Empty Filenames on NFS in Linux Emulation

J

jwillia3

FreeBSD 15.0-RELEASE:

Before I file a bug report, I wanted to get an idea of if this is just my setup or if others are having this problem.
Listing NFS directories from Linux-emulated binaries causes zero-length directories to show up.
Ex:
~$ /compat/linux/bin/ls -aQ /share
"" "" "" "" "" "" "" "." "other files"
"" "" "" "" "" "" "" ".." "etc"

These no-name directories show up when reading an NFS directory from Linux.
They do not show up from UFS.
They also do not show up from FreeBSD.

Anyone have similar experience?
 
Never mind. Reproduced with Linux server and NVFv3 under 16-current.
Code: 
~(joker)89% /compat/linux/bin/ls -F /mnt/tmp
''/  ''/  ''/  ''/                6.1.0-38-amd64/             default@
''/  ''/  ''/  ''/                6.12.13-cracauerdlwavehh/   kernel/
''/  ''/  ''/   6.1.0-26-amd64/   6.15.7-cracauerdlwavehh/    modules.order
''/  ''/  ''/   6.1.0-27-amd64/   build@                      source@
 
Problem seems to be that getdents64(2) returns 26 instead of 12 entries.

openat(AT_FDCWD, "/mnt/tmp", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents64(3, 0x104a550 /* 26 entries */, 32768) = 768
 
Gets more wild:
Code: 
/compat/linux/bin/bash -c 'cd /mnt/tmp ; find . -maxdepth 2'  2>&1 | less
# try that on a tree in there, it'll dig up more "no such file or directory"

I think the root cause is that FreeBSD's getdirentries(2) can fill the d_off field with 0 when operating in the NFS client, and the linux_getdents64(2) on top doesn't understand that.

However, this works correctly:
Code: 
/compat/linux/bin/bash -c 'cd /mnt/tmp ; echo *'

So bash is doing something different for its globbing. Or maybe it just filters.

ETA: yes, bash also gets 26 entries, which it shouldn't, but it doesn't print the junk entries because they don't match '*'.
 
You must log in or register to reply here.
Back
Top