09-11-2009 03:30 PM
(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.
09-11-2009 03:47 PM - edited 09-11-2009 03:47 PM
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:
Incorrect Results with "!file.txt" in #5 above:
Command Prompt example showing different sort order for "file.txt" & "!file.txt" on a mapped network drive:
09-11-2009 03:54 PM
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
09-14-2009 11:36 AM
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 ..?
09-14-2009 11:54 AM
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". 😉
09-14-2009 12:09 PM - edited 09-14-2009 12:12 PM
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 .
09-15-2009 03:03 AM - edited 09-15-2009 03:04 AM
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
09-15-2009 07:13 AM
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
06-19-2018 12:57 PM
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.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
16 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
06-19-2018 01:35 PM - edited 06-19-2018 01:43 PM
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.