Windows Shortcuts (.lnk) Become Part of LabVIEW Expected File Path

[NI-hilator]

After much frustration searching the Labview help and NI website I finally came across the reason why my project kept coming up with vi file conflicts and/or using the incorrect version of a vi.  Apparently when searching for a vi, if there is a windows shortcut (.lnk) in the search path, it follows it!  Now this is a very powerful feature but a dangerous one too.  Apparently this has been a feature of Labview all the way back to version 1.0 This fact is not mentioned anywhere in the Labview help but I did finally find this article: http://digital.ni.com/public.nsf/allkb/B43C655BA37AFFA0862575EC0051E936

In my case I have lots of example code on my PC. I often put shortcuts to similar code in the same folder with VIs and project as a quick way to reference alternate methods of accomplishing similar tasks.  No problem, I'll just turn off this feature in the VI Search Path page of the Options dialog, right?  Much to my surprise there is no way to turn this off.

Suggestion: Please add an option to disable this feature in the VI Search Path page of the Options dialog.  Even if this option is dismissed and not implemented, please at least add this information to the Labview help, perhaps in the Paths Page (Options Dialog Box) if not in several other places in the help. It would certainly have same me hours of frustration and lost productivity. 

[Intaris]

Lots of windows programs do this.  It has to do with an API change from Microsoft.  It's not a "Feature" that was actually ADDED to LV, it just happened over time that the lnk was returned by a windows process as being a directory.

But I would certainly like the option to turn it off (Add some more intelligence to LV).

[NI-hilator]

Thanks for chiming in Intaris.  Not sure about it happening over time because according to the article in the link I posted this has always been a feature of Labview... since version 1.0.  Regardless, it would be good to have the setting.

[Intaris]

The file .lnk was introduced with Windows 95 so LabVIEW 1.0 certainly had nothing to do with this issue.  I'm assuming you're referring to the software version listed on the document you linked to.  I'm really not sure that's reflecting the LabVIEW version.  As such I can only point you to my original response.

[AristosQueue (NI)]

LabVIEW has no idea that it is following a link. Links are indistiguishable from regular directories and files to applications --- that is by design of the operating system. It would substantially slow down LabVIEW to query whether every file and directory is real or is just a link.

Stop putting links into your directory structure if you don't want those links to be part of your directory structure. Perhaps it would work to push your code down one more level of directory so that your links can be in a directory higher than the project and its source code?

[seeker169]

This one bit me a couple years ago when somehow a link to a vi -- on a different computer -- ended up in a search path.  If my computer was off the network, there wasn't a problem.  But if it was on the net, LV would take *forever* to load my project.  No errors were thrown since the vi link wasn't actually used, which made it a beast to hunt down and fix.

[EduNI]

@AristonQueue wrote: "LabVIEW has no idea that it is following a link. Links are indistiguishable from regular directories and files to applications" 

If LabVIEW has no idea that it is a link and that it is indistinguishable then how is LabVIEW able to offer a "File/Directory Info" VI that report back if it is a shortcut?  This is a quote from the 2015 help "File/Directory Info Function - Returns information about the file or directory specified by path, including its size, its last modification date, whether it is a directory, whether it is a shortcut, and the resolved path if the file or directory is a shortcut"

LabVIEW 2015 Help File/Directory Info Function

At a minimum NI should acknowledge that this behavior is not always desirable and offer a setting to turn it off.

[AristosQueue (NI)]

If we explicitly request the information about links, yes, we can find that information. But that information is not a part of the directory traversal information that we typically request, and adding link information to it would slow down the system considerably.

Applications are supposed to treat links as directories. Having applications have special behavior for links largely defeats the purpose of having links unless that application is explicitly made for manipulating links (which is why we expose the functionality for you to use if you need it in the app you're writing using G).

[EduNI]

"Applications are supposed to treat links as directories. "  Says who? Where is this written that this is required or is good programming practice? I have never seen any other application treat links as if they were directories. That doesn't mean there isn't but I have never witnessed it. "...adding link information to it would slow down the system considerably."  As opposed to following a links it doesn't need to follow? Even so, whatever the reason for not implementing this suggestion, what would it hurt to add this information to the LabVIEW help?

[Intaris]

I think it's also important to distinguish between junction points, file system redirects and shortcuts.

While I would agree that your typical OS-level junction points and redirects should be followed as if they were real directories, I think the idea of following a shortcut (i.e. a file designating a link, not a File system entry in itself) is flawed.

[sci7]

Did anyone check cmd? Windows does list them separately, so Labview should be able to tell the difference.

First image is with a folder named "PROJECTS (Y) - Shortcut" and a shortcut named "PROJECTS (Y) - Shortcut.lnk". First is listed as a "Dir", and the other has a file size. If you try to rename the folder, and add ".lnk" to the end, you will be told that a folder with that name already exists.

If you delete the shortcut and then rename the folder to "PROJECTS (Y) - Shortcut.lnk", the folder is listed as a directory. (Second image).

If you did a search to exclude all files ending with .lnk, Labviews "List Folder" would not be able to tell the difference between a link and a directory as it is right now.

Yes, no tech savvy person would name a folder with ".lnk" in it, but if a user is able to do it, someone will do it.