This problem occurs with the NFS client from SFU 3.5 on XP SP3, as well
as with the NFS client from the on-board SFU on Windows Server 2008.
Consider a directory tree on a NFS share on some remote NFS server box
which, just for instance, is 1K chars deep, and every subdir contains
just one more subdir:
Now you start a simple testcase which does basically this (vaguely
C-shaped pseudo code):
allocate PFILE_NAMES_INFORMATION buffer of 60K
native_nt_dirname = "\\??\\UNC\\server\\share\dir"
while length (native_nt_dirname) < 1024
status = NtOpenFile (&handle, dir)
status = NtQueryDirectoryFile (handle, [...], buffer, 60K,
FileNamesInformation, FALSE, NULL, TRUE)
[skip . and .. entries]
if (NT_SUCCESS (status) && is_a_dir (buffer.entry))
native_nt_dirname = native_nt_dirname + "\\" + buffer.entry
I don't know if my pseudo code is clear enough, but the real code works fine
for long path names of up to 32K on NTFS, but it fails on NFS as soon as
the native_nt_dirname is longer than about 260 WCHARs. Which is *very*
What fails is *not* the NtOpenFile on the dir, but rather the subsequent
call to NtQueryDirectoryFile. It also fails with a rather weird status
code, STATUS_BUFFER_TOO_SMALL. I tried various code changes like
reading only one directory entry at a time instead of what fits into the
buffer, or using the FileDirectoryInformation class instead of
FileNamesInformation, but to no avail.
The bad joke is, this only happens with NtQueryDirectoryFile. Calls
to NtQueryInformationFile on files on an NFS share with any length
This occurs in our Cygwin lib. The effect is that an `ls' shows no
files in a subdir > 260 chars, but a 'stat dir" within the same
directory works fine. Then ls again doesn't work, but a cd works, and
so on. Calling stat (which basically translates to NtQueryInformationFile)
at any point in the directory tree shows that the subdir exists and every
one has another inode number.
For the sake of sanity, I tried this with a SFU shell from SFU 3.5 on
XP and with a SFU shell on Windows 2008. And guess what? It suffers
the same problem. It doesn't recognize any directories below a path
of ~260 chars because NtQueryDirectoryFile fails. But it's no problem
to cd into the next subdirectory if you happen to know its name.
Additionally it should be noted that the 260 chars border doesn't make
any sense on the native NT level, which Cygwin as well as SFU utilize.
Is this perhaps a known bug in the NFS client?
Cygwin Project Co-Leader