LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

List Folder Returns Incorrect Results for Folders on Network Drives

(crossposted to LAVA)

 

I'm seeing a behavior where LabVIEW's List Folder primitive returns incorrect results for a folder on a mapped network drive, if the folder contains a file whose name starts with any of:

<space> ! # $ % & ( ) + , -

(I suspect it's actually any ASCII character whose value is less than or equal to 0x2D, but some of those are illegal and/or unprintable).

 

OS: WindowsXP
LV Version: LabVIEW 8.6 and LabVIEW 2009

Steps to Reproduce
(1) Map a network drive to a drive letter (I'm not sure that a mapped drive is necessary, and the network drive in this demonstration is a samba share from a Linux system).
(2) Create a file in a directory on the network share from #1, e.g. "Z:\list-folder-bug\file.txt".
(3) Note that LabVIEW's List Folder function returns correct results when listing the folder you just created.

Attached Image


(4) Rename the file you created in #2 above, changing its name to !file.txt. (The key is that the filename must start with !, or any of the other characters listed above.)
(5) Note that LabVIEW's List Folder function now returns two elements in folder names that don't really exist.

Attached Image


Why This Is Important

This is important because these phantom directories "." and ".." are expanded to "current directory" and "parent directory," which means LabVIEW thinks that the target directory contains a copy of itself and its parent. This produces an infinite recursion when listing directory contents recursively. In particular, the OpenG function List Directory Recursively is affected by this bug and enters an infinite loop when run on the directory shown in #5.

Bonus Information

Note, also that the dir command at the Windows Command Prompt sorts the file list in an odd way for files that begin with the aforementioned characters, but only on network shares.
Attached Image

 

0 Kudos
Message 1 of 25
(6,713 Views)

I think I screwed up the inline images and my post edit time has expired (although they appear OK for me right now), so here they are again.

 

Correct results with "file.txt" in #3 above:

 

expected-result.png

 

 

Incorrect Results with "!file.txt" in #5 above:

 

actual-result.png

 

 Command Prompt example showing different sort order for "file.txt" & "!file.txt" on a mapped network drive:

 

command-prompt.png

Message Edited by Justin J. Goeres on 09-11-2009 03:47 PM
0 Kudos
Message 2 of 25
(6,705 Views)

I've seen problems like that before and the only thing I could come up with was not to let the user create files with those characters in them.  😞

 

I hope there's a better way than that...

 

Bill

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 25
(6,699 Views)

Hi Justin,

 

Just as ShaunR on LAVA, I was unable to replicate your behavior on my machinein either 8.6 or 2009.  If you remember your good ol' DOS, also as ShaunR mentioned, the . and .. are used to navigate upwards using cd.  Perhaps the best solution is to modify the recursive VI to ignore directories that are . or ..?

Stephen Meserve
National Instruments
0 Kudos
Message 4 of 25
(6,659 Views)

Interesting Justin..

 

I recall seeing something like this back in 2005 with LV7.1.  I was communicating with Linux Embedded and had to retrieve files, and create files and directories (folders).  I can't recall the exact details.  However, I do recall messing up the file structure for the device because it created filenames "." and "..".  I had checked everywhere to how the dot filename got created and never found anything.  I came up with some workaround where the file was created on the local test PC and telnet to the Linux file system.  Now, I can't remember the filenamesthat were used, as they were created by the software guys.

 

Since I no linger work there, I cannot go back and check that hypothesis.. 😞

 

Maybe the problem resides with LabVIEW dealing with Windoze talking to "Unix".  😉

 

 

Message 5 of 25
(6,654 Views)

 

Maybe the problem resides with LabVIEW dealing with Windoze talking to "Unix".  😉

 


That was my feeling as soon as I saw the odd behavior at the Windows Console.

 

Probably somewhere between Windows being weird and Windows talking to Unix/Linux, the directory results are getting reported back to LabVIEW in an unexpected way.

 

I'm not surprised that it doesn't reproduce easily.

 


 

If you remember your good ol' DOS.

 


 Or, alternatively, modern-day Unix/Linux/OS X Smiley Happy.

Message Edited by Justin J. Goeres on 09-14-2009 12:12 PM
0 Kudos
Message 6 of 25
(6,645 Views)

LabVIEW on Windows seems to use FindFirstFile() and FindNextFile() to implement the List Directory functionality and those do return the . and .. as entries in the directory. Apparently LabVIEW filters them out for good reasons but that filtering gets somehow misguided if the directory is on a network share (possibly only Unix network shares) and contains a file starting with a non alpha-numeric character.

 

Seems to me like a bad interaction between the Windows API and the underlaying network provider resulting in something the LabVIEW code doesn't account for.

 

The immediate OpenG fix would be to filter for those directories anyhow, eventhough they are usually not present.

 

Rolf Kalbermatter

Message Edited by rolfk on 09-15-2009 10:04 AM
Rolf Kalbermatter
My Blog
Message 7 of 25
(6,616 Views)

I should try an experiment at the home office.  Although I doubt it will reproduce it.

 

I have a LinkSys NAS200 which runs Linux.  However, it uses an NTFS file system for network access.  I wonder if a more native file system (to Unix) would make the difference..  I could try the experiment by turning on the good old Ultra Sparc-10 and accessing the files on that machine over the network.  

 

Should that prove to be the case, then we would have identified a bug..   

 

I'll try to make the time to experiment.

 

I doubt that the problem would show up on a Windows mapped network folder (from another Windows machine).

 

R

 

 

0 Kudos
Message 8 of 25
(6,603 Views)

Years old thread I know, but I'm seeing this issue today in LabVIEW 2015 and was wondering if anyone figured out what the heck was happening, or if this has been fixed in newer versions.  I actually found this because the recursive file list got stuck in an infinite loop.  After looking at the source it was because it kept returning its parent directory, as a directory under itself.  The computer this is happening on only has 2015.  All other network computers seem to return the expected result in 2017 and 2018.  For me this seems to be linked to the folder that starts with a "-".  If I change that to some other character it works as expected in 2015.

0 Kudos
Message 9 of 25
(5,061 Views)

Could be indeed your culprit. In DOS the . folder was the current folder. And the underlaying directory enumeration API in Windows does always return that folder too together with the .. which is the parent folder. LabVIEW does attempt to remove these folders from the enumeration before building the path list to return but it's very possible that some weird interaction with an underlaying network file system driver causes something that older LabVIEW versions were chocking on when trying to remove those superficial directory entries.

 

As far as I remember the List Directory function assumes that the . and .. are returned by FindFirstFile() and FindNextFile() as the first two entries and that loop aborts as soon as it finds a file that does not match these two file names. After that it goes into the loop that creates the file and folder list and does not filter out those folder entries anymore. So your non-standard filename starting with a non alphanumeriek character is somehow returned by the underlaying file system driver in a different order than what DOS/Windows used to require and the LabVIEW assumption goes wrong. Seems someone in the LabVIEW team did fix this in one of the recent versions.

Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 25
(5,054 Views)