LabVIEW
Copy a shortcut to a file using LabVIEW?
I got the method to copy all your .LNK files ....to any location ......just workes a little on tst's "copy lnk.vi", & it works.....the only problem was with white spaces...poor cmd does not recognise ...white spaces...so it returns "file not found".....BUT now it does.....!!! Chk out the attachment....!!
It’s not a bug at all but a feature. When you specify a path with a .lnk file in it, the LabVIEW path will always be resolved to the real path before trying to do any file operation on the path. The only way to treat lnk files as actual files is by avoiding the LabVIEW path datatype entirely. But the lnk file is a DCOM based extension of the Windows shell, not the lower level Windows API. This means that if you copy a link file to a different location with low level Windows APIs or the command line tool it will generally not point to the original file, since that location is stored in relative form inside the link file, which will then point into nirvana relative to the new location.
There are some shell32 Windows APIs that can properly deal with lnk files but they generally work on IDLists, another marvelous invention of the early Windows Internet Explorer developers who thought to invent a completely novel file system view on top of the Windows 95 volume system. Only to be overtaken by the Windows NT guys who developed a real new file system management onto which the old DOS system was mapped to, rather than the other way around. But by that time the bad had already happened and the not really officially documented Win95 pseudo file system was moved info its own shell32.dll together with lots of IE crap and under a court order also officially documented. The rest is history as they like to say.
The whole is a total mess of inconsistencies, compatibility hacks and half documented features. I’m sure that the LabVIEW developers brainstormed many times about how to solve this properly and that there was no satisfactory solution that wouldn’t have meant to introduce a whole palette of extra file primitives and/or rextra enum parameters to every single file IO function. Add to that the fact that the Windows link files have significant semantic differences to Unix symlinks and Windows despite having low level support on NTSF for symlinks since at least Windows XP, even Windows 10 doesn’t support them on user level as fully supported entity. The explorer can deal with them but if you want to create them you have to resort to 3rd party tools or the command line! And they are so dangerous that under Windows only an elevated account is allowed to create them by default!
