Copy.vi resulting in No_More_Files error when copying to Windows 2019 server

[AllisonSCJ]

When copying roughly 10 jpg type files of 10-20kb, I noticed that only have of the image files were making it to the server destination.

This appears to be an issue with the Labview copy.vi and Windows 2019 server. The source PCs exhibiting the issue are two Windows 10 PCs. I'm using the 2016 version of the Labview suite.

I replicated the issue with the simple vi attached below, and captured a wireshark trace which showed a No_more_files error during copy when replicating the issue.

The steps I've taken to debug the issue are as follows:

1. I was able to replicate the issue in Labview 2019.
2. An OS specialist at my copy checked the success audit on the server and found no issues
3. Checked for file locks that may be causing the issue; no files appeared locked when replicating the issue
4. A network specialist checked for network issues and didn’t find any
5. confirmed there is no LAN data capping employed
6. I recreated the issue on two Windows 2019 servers, on multiple folders regardless of path length
7. The issue could not be recreated on a Windows 7 server
8. I tested for the issue using Windows File Explorer; the issue was not replicated
9. I tested the issue using cmd xcopy; the issue was not replicated.

Possible next steps:

1. Wireshark confirms that the file copy is using SMB 2.0. I will attempt to enable SMB 1.0 on the Windows 2019 server, as per instructions in the thread here 
2. A Microsoft thread here mentions the error I'm experiencing and mentions the error may be due to security software. I'm working with my company tech support to check this, but given that the error is only replicated with LabView's Copy.vi, I'm inclined to think the vi is not capturing an error as it should, or is not interacting properly with the 2019 file structure in some way.

[AllisonSCJ]

Further information:

According to ProcMon, the copy.vi is making a call to the QueryDirectory operation to check if a file exists in the target directory or not. It appears to be this call that leads to the No_More_files error. Digging into the QueryDirectory operation shows that this operation uses FindFirstFileW and FindNextFile API calls, meaning that the LabView Copy algorithm checks the target directory similarly to the Dir command.

I recall from the NI thread here that List Folder.vi, which also uses the dir algorithm, will get stuck in a recursive loop on directories with special characters when querying a Windows 10 directory. I wonder if this behavior is related to my issue? The directory I am querying does not include special characters. However, I could imagine that a recursive loop could lead to memory issues which would then return a No_more_files error.

[rolfk]

FindFirstFile() and FindNextFile() are basic Windows APIs to check for presence of files or to enumerate them. Any Win32 API software dealing with files will use them somehow unless you want to directly go through the Win NT kernel interface functions in nt.dll, which Microsoft discourages to do. The List Folder node in your VI uses exactly these functions to enumerate the source directory. The Copy node may use the FindFirstFile() function to check for the presence of the file in the target path but shouldn't really need to call FindNextFile(). It could also call GetFileAttributes() instead to check for the presence of the file and that would very likely result in a similar SMB command stream. From a client respective FindFirstFile() is similar to GetFileAttributes() but returns additional information about the file entry and not just the basic file attributes and indication if the file or directory exists. I could imagine that on the SMB level it also uses the same or a similar request.

The NO_MORE_FILES error seems to come from the server so it would be interesting to look at the request just before that to see what path was requested info for.

It may be related to the other issue but not necessarily. The issue in the thread you mention is that if special files or directories are located in a directory, that alphabetically sorted appear before the . and .. entry, then the List Folder function will fail to filter out the . and .. directory entries as it assumes that they are always the first two entries returned by FindFirstFile() and FindNextFile(). That was apparenty not an issue for SMB1 volumes as the SMB1 driver sorted the file entries accordingly that the . and .. entries were always the first two, and is still not an issue for local file systems, but SMB2 seems to have abandoned the DOS compatibility sort order.

The List Folder node itself won't get stuck in an endless loop. The Recursive File List.vi convenience function however will, as it falsely will attempt to enumerate the two returned . and .. entries in LabVIEW versions prior to 2019.