One of my projects at work is to update a station currently using some LabVIEW VIs from a previous version (running under TestStand). So I downloaded all of the code from source control, branched it, and then told LabVIEW to mass compile the directory, with the idea that I could upload all the recompiled VIs to the branch first thing, so that any subsequent changes I made would be on separate commits to source and easier to identify later if I need to make a list of things that changed.
Imagine my surprise when I get an angry e-mail from a co-worker informing me that I broke the station. After investigating, it turns out that buried 3 directories deep in the source code, the former author of that station (an ex-employee) had for whatever reason linked one of the VIs in that directory to a subdirectory on a network drive, and had left a shortcut to that file in the directory of the calling VI as a "helpful" reference, and LabVIEW decided that meant it should be recompiled with everything else (despite not being in the actual directory structure I targeted).
Now we've obviously resolved the problem by reverting back to the old SubVI from backups and the station is back up, but the reason I'm posting is that I'm wondering if this is an intended behavior or not. I was under the impression that "Mass Recompile" would only ever target files in the target directory or subdirectory. It was obviously a bad choice of our former employee to link to a network file and leaving a shortcut instead of copying the network file into the source tree, but I'm wondering if this is a "feature" that I just didn't know about (and to be fair, probably rarely would occur) or if it's really what "mass compile" should do.
Solved! Go to Solution.
It is intentional: Windows Shortcuts (.lnk) Become Part of LabVIEW Expected File Path
Well, I now know not to put shortcuts into my VI directories unless I want it to be like they're actually there, and I'll be double-checking that ex-employee's code for unintentional booby traps a bit more carefully (I mean, who puts one VI out of 300 on a network drive...)
I'm guessing I didn't find that page because all of the searches I did involved the words "mass compile" as I didn't know it was a thing for LabVIEW in general.
While it is some extra work an application has to do to actually resolve a .lnk file, which LabVIEW obviously bothers to do, I would not say this is a very unexpected feature, but that is from a background on having experience with Unix systems which commonly use hard and soft links in the system and where user applications generally have to do extra work to not treat those links as the actual target file.
The .lnk files in Windows were the Microsoft poor man variant of what you could do on Unix from pretty much the beginning. And because they were implemented in the shell rather than in the file system, an application had to do extra work by calling some shell COM object interface to treat them as what they were meant to be, rather than a bunch of undocumented bytes, pretending to be a link to a different location.
The LabVIEW developers, having been designing LabVIEW as multiplatform application from version 3.0 on and supporting a Unix variant (Solaris) together with the Windows version, obviously thought it was a good thing to add support for the Windows .lnk file to work similar as the Unix hard and soft links. And generally it is! There are exceptions to that, which you have run across. Other exceptions would be if you intend to write a backup application in LabVIEW. That are the applications where on Unix the programmer has to call special APIs to detect that a file is in fact a link rather than the real file and then backup the link itself instead of the target file. But the cases where someone writes a backup application in LabVIEW are pretty uncommon!
Windows implements nowadays also hard and soft links, before Windows XP only with pretty obscure kernel calls, that only supported hard links that are called "reparse points" under the NTFS file system. In Windows XP one could install a kernel device driver from a third party that implemented support for hard and soft links for user applictions on top of the newer NTFS kernel driver that supported them and since Windows Vista/7 it has that kernel driver itself in the system out of the box. There are even Windows 32 bit APIs to create them in Windows 7 and later, but to query them like what a backup application would need to do, you still have to call into the kernel driver itself to query the path to the target location. Most of the Windows APIs do not follow a soft/hard link automatically so if you call the DeleteFile() function with a path to such a link it will delete the link and not the target file, but if you call CreateFile() (sic!) to open a file handle it will follow any link and open the actual target file rather than the link itself, unless you pass a special flag to the CreateFile() function. Sort of inconsistent and confusing if one ever starts to bother about that, but all in the name of compatibility with applications that have been written before hard and soft links were possible and therefore do not care. And most Windows applications except backup programs are even nowadays still totally oblivious to the fact that there are things like hard and soft links.
Some are not like the Windows upgrades, but not in a good way. They will totally bork if a user happened to have relocated his home directory to another location through the use of soft links.