LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Recursive File List VI stuck in loop.

Solved!
Go to solution

Ah, I did not notice the word "network" in the original post. ...


LabVIEW Champion. It all comes together in GCentral GCentral
0 Kudos
Message 11 of 17
(230 Views)

Yep... same thing.  I just ran it on a local folder with the same files and it worked fine.  Puzzling that it only started happening recently on newer PCs though.  We have been saving files in that format to the same drive and have been using the same software for quite some time now. 

0 Kudos
Message 12 of 17
(228 Views)

@altenbach wrote:

Ah, I did not notice the word "network" in the original post. ...


I didn't either.  Smiley LOL

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.  

aputman
LabVIEW 2017
LabVIEW Programming
0 Kudos
Message 13 of 17
(225 Views)

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. 

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Message 14 of 17
(214 Views)

I'm experiencing the same issue, the '.' and '..' are special characters meaning previous, and 2nd previous folder.

Marking the root and 'ready for archiving' removes these two folders from the list.

 

0 Kudos
Message 15 of 17
(152 Views)

@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.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Message 16 of 17
(123 Views)
Highlighted

@aputman wrote:

https://forums.ni.com/t5/LabVIEW/List-Folder-Returns-Incorrect-Results-for-Folders-on-Network/td-p/9...

 

Same issue seen here.  Haven't read thru the full post yet.


The fix I described in that thread is present in Recursive File List.vi in LabVIEW 2019 and later.

DNatt, LV R&D
Message 17 of 17
(94 Views)