From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Recursive File List VI stuck in loop.
Solved!
@altenbach wrote:
Ah, I did not notice the word "network" in the original post. ...
I didn't either. 
I read the problem as a file that was being sent from a PC on the network to this computer...not that it was still being stored on the network.
I think the problem is related to a NetBIOS change somewhere in the past that modified the way directory listings are returned. Until then DOS/Windows always put the . and .. entries at the start of a directory enumeration. For network paths this functionality gets simply forwarded to the NetBIOS driver. For some reason they changed the NetBIOS directory enumeration to return the entries in full alphabetically order making the . and .. entries appear in different locations than the first two, if there is a directory or file entry with a special character that is before the decimal point in the ASCII list. LabVIEWs internal list directory function used to go first through a loop of up to two iterations to skip those entries and would abort that loop as soon as one of the returned entries was not . or .. After that all the remaing entries are enumerated and returned. So if you have a special file or directory entry in there that starts for instance with $, & +, - or a similar character it will appear before the two directory entries and the first loop will be aborted immediately. Then all remaining entries are returned including those two "special" directories.
@AllisonSCJ wrote:
I'm experiencing the same issue, the '.' and '..' are special characters meaning previous, and 2nd previous folder.
Not quite! . is current directory and .. is parent directory. For programmatic access they are both totally useless, especially the current directory entry. LabVIEW's internal directory enumeration function consequently attempts to remove them for its own use.
The Windows directory enumeration will always return these two entries (except for the root of a disk drive). Until recently it always returned them as the first two entries and LabVIEW was counting on that by simply throwing away the first two returned entries. A few years ago something suddenly changed in Windows. For local drives it still returns these two entries as the first two but for network paths it relies on the network protocol driver to do the enumeration and some of them started somehow to not follow this rule anymore.It's still a very rare problem and also has to do with what type of protocol versions are enabled or not. One possible change might come from the complete disabling of the SMBv1 protocol in recent Windows versions due to its inherent security problems. In addition Windows versions before 1803 did not seem to be affected except for some SAMBA served network paths sometimes.
Yes it could be considered a bug in LabVIEW to assume that these two entries are always the first two rather than that they could appear anywhere in a directory listing. But a bug that until about a year ago had almost no practical consequences. Considering that Windows was doing it for 25 years like what LabVIEW assumed, you could actually say that the Windows change is the real bug.
So get NI involved and get a SR number issued and an according bug number.
Here's a screenshot of the updated VI from LabVIEW 2019, with the relevant changes noted in red.
