List Folder Returns Incorrect Results for Folders on Network Drives

[Darren]

Do y'all think I should make a change to Recursive File List.vi to prevent this from happening in the future? Like adding a subVI like this to filter the 'folder names' output of the List Folders function?

[Hooovahh]

---

@Darren wrote:

Do y'all think I should make a change to Recursive File List.vi to prevent this from happening in the future?

---

That's exactly what I did in this one project that is still in 2015.  But if we can assume that List Folders works properly, then this shouldn't be a bug in Recursive File List.  I don't think we should be patching Recursive File List (and making it slower) because a bug exists (existed?) in List Folders.  That being said it was pretty annoying tracking this down since the program just appeared to lock up one day.

[Darren]

---

@Hooovahh wrote:
That being said it was pretty annoying tracking this down since the program just appeared to lock up one day.

---

Yeah, that's why I figured it might be good to make the change, just to future proof the VI against weird OS-level issues that may randomly pop up again. I don't think the For Loop will have an adverse effect on performance (relative to how long the List Folder disk operation takes). Let me know if anybody else reading this thread has an opinion on whether I should make this change.

[rolfk]

Well it does seem that someone made a fix in filemgr.cpp to properly filter those two directories even if they don't appear as the first 2 entries from FindFirstFile/FindNextFile. And since nobody is going to put this fix automagically into older LabVIEW versions, I'm not really sure that such a fix still has much of merits now. The earliest version such a VI will be included in will be 2019. And as the root cause seems fixed in at least 2018, so what?

But it should be trivial for you Darren to check the bug data base for that fix and a quick look in the source code will easily tell you if this fix is really implemented.

Instead of just skipping the . and .. folders before going into the enumeration loop, the code for filtering these two entries should be inside the enumeration loop.

[Ironman_]

it is NOT fixed

I can sistamatically reproduce the bug

windows 10 1803

LV 2018

\\server\folder

"folder" has NO subfolders

if inside "folder" there is a file whose name starts with "$" ---> you get [ "." , ".." ] array as output (which is INCORRECT)

if folder doesn't contain files with those chars.... you get empty array as output from List Folder VI

NOTE : WITH WINDOWS 1709 IT'S OK. YOU NEVER GET [ ".", ".."]

[Samuel.J]

Ironman_,

Thank you for continuing to check on this. Since this is such an old forum post could you make a new post, linking to this one with the code you used to check for this behavior? If we can confirm this is a bug then we can get a report filed with R&D and see if they can get another fix out.

[Darren]

I have filed CAR 705779 to add logic to Recursive File List.vi to ensure it doesn't ever try to recurse '.' or '..' if they are returned by the List Folder call.

[Darren]

P.S. - I can reproduce the behavior described above, where having a network folder with a file starting with "$" causes the "." and ".." values to be returned by List Folder. And the behavior is different in the latest Windows 10 update vs. earlier versions (or Windows 7, which also doesn't exhibit the behavior). I'll leave it to Sam and the PSEs to determine the best course of action for the different List Folder behavior between Windows OSes.

[rolfk]

Also please note that fixing the Recursive List Folder.vi is only a patch for the wrong behaviour of the underlaying List Folder node. And the functionality used by the List Folder node is internally used by the Move File and Copy File node when it copies a directory recursively. And here the result is nasty!

Because the underlying function FListDir() can return the "current directory" and/or "parent directory" entry, the recursive FMove() or FCopy() operation will never terminate and at some point run into an out of memory crash as the number of folder paths to copy will keep growing!

[Ironman_]

Ok so now that bug is confirmed, the question is:

1) when will the fix available

2) how can I install the patch? via "NI updater service"?

3) the patch must be done up not only to LV2018, but also for LV2017, LV2016 and  LV2015 (this is still supported - until end of 2018 I guess).

Don't try to play the game "buy the most recent LV".

LOL