Darren's Weekly Nugget 12/28/2006

[Darren]

Hello all,

Sorry for the late nugget, I just got back into Austin yesterday from visiting family for the holidays.  Anyway, today's nugget has to do with file shortcuts and potential problems you can have with them in regards to the File I/O functions in LabVIEW.  Check out this VI, which simply uses the List Folder function to return the top-level contents of my C drive:

Check out the "folder names" list...see the "Shortcut to C.lnk" entry in there?  That's a shortcut I created to my C drive.  The fact that it appears in the folder list could pose a problem if I am using the List Folder function in a loop to recurse the contents of my C drive...specifically, I'd probably get into an infinite loop because I would keep listing the contents of C drive, getting C drive in the folders list, listing its contents, etc.  There was really no hack-free solution to this problem in LabVIEW 7.1 and earlier.  But with LabVIEW 8.0, we got a new output on the File/Directory Info function:

See the "shortcut" output?  Notice how it's TRUE when checking the info of "c:\Shortcut to C.lnk".  So now, in your recursion operation, you can check the info on a folder path before you attempt to recurse it...if it's a shortcut, don't recurse it.

Note that this problem currently exists with the Recursive File List.vi on the File I/O > Advanced File Functions palette in LabVIEW 8.2.  I am going to fix this VI in the next version of LabVIEW so that it does not recurse shortcuts.

-D

P.S. - Check out past nuggets here.

Message Edited by Darren on 12-28-2006 11:43 AM

[sth]

Darren,

A very necessary extension! Now my question is how does this feature on Shortcuts translate to "aliases" and "Symbolic Links" on an alternative platform (OS X for both and Linux for the latter). Directories can't have hard links so that kind of loop is avoided. Does the VI distinguish between Aliases and Symbolic Links?

-Scott

[Darren]

Hi Scott,

I'm just a Windows jockey, so I'm not sure what the behavior is with Aliases and Symbolic Links on Mac/Linux.  I have an e-mail out to one of my colleagues who should be able to give us a more complete answer.  I'll let you know when he gets back to me.

-D

[altenbach]

---

@Darren wrote:
I'm just a Windows jockey,...

---

OK, a Windows question:

Am I correct to assume that links always end in ".lnk" (under windows). If this is true, we can just weed out the stuff that matches ".lnk$" or similar. I faintly remember that I did something like that years ago... 🙂

[Darren]

Yup, unless some doofus names one of his folders something like 'folder.lnk'.  Then you have to add a check for that...and there's probably other corner cases you'd have to hack around too.  I think using the 'shortcut' output of the File/Directory Info function is probably the cleanest solution.

-D

[altenbach]

---

@Darren wrote:
Yup, unless some doofus names one of his folders something like 'folder.lnk'. 

---

Ouch, Yes!

The new info tool is certainly the best! Hopefully, all users will upgrade. 🙂

While not entriely "hack-free", filtering for .lnk$ is probably sufficient for pre 8.0 users. I don't remember running into any issues when I used this method very, very long ago.

[ratkindler]

I hope someone sees this post, considering how old this thread is.  I'm encountering the exact problem described here using Labview 7.1.  The recursive file list.vi is choking when it encounters a *.lnk file.  Can someone suggest a method of filtering these out from within the recursive file list.vi?  It accepts a start path as input and then goes through each folder in that start folder using the list directory.vi.  I think it's when a *.lnk shortcut is passed to the list directory.vi is when it chokes.  It seems to me that *.lnk files would have to be filtered out before this point.