So I created a symbolic link using the system exec command in Windows 7 x64 with LabVIEW 2015 SP1 32-bit. The command is something like the following:
cmd /c mklink /D "C:\Folder That Does not Exist" "C:\Real Folder With Data"
This will make a folder named "Folder That Does not Exist" that you can double click on and it will open but show the files and folders in the folder "Real Folder With Data". This works great and the external software that has hard coded paths works as expected. But when I am done with this I want to remove the symbolic link, which in a normal instance this would mean just deleting the folder at "C:\Folder That Does not Exist", but doing this with the LabVIEW Delete function on the File I/O palette generate an error 6 Generic File error. If I enable the Entire Hierarchy delete then it does delete the symbolic link...but it also deltes all files and folders in the "C:\Real Folder With Data" folder which isn't what I want. Is this a bug? Can NI assign a CAR to get this fixed? Is there another way of deleting this symbolic link other than a rmdir command line call? Thanks.
Take a look at this link. https://superuser.com/questions/167076/how-can-i-delete-a-symbolic-link
I wouldn't think that deleting the folder would just kill the symbolic link and not kill the target folder in any instance. And that link I gave above seems to indicate that as well. It says you need to use rmdir to break the symbolic link.
I wouldn't think that deleting the folder would just kill the symbolic link and not kill the target folder in any instance.
Well then hitting the delete key when the symbolic link is selected in Windows Explorer is performing the rmdir, because that's how I delete them normally and it doesn't delete any linked data.
The first answer in this reply to the same question says to "simply delete them as if you’re removing a normal file. Just make sure you don’t delete the original file". In my code I now use another system exec to rmdir but I would be more convenient if the NI primitive Delete worked on symbolic links.
This is a tricky one. Microsoft needed a VERY long time to support something that resembled the symbolic links that Unix knows since basically the beginnings. The Windows 2000 NTFS system started to support junctions points that could be used similar to a Unix hard link for folders, only there were no system tools to create, modify and delete them!!
The NTFS driver shipping with Windows XP then introduced also support for files. Still no official tools were available to actually use them. Some people found inoffical ways to directly call into the file kernel driver to use these features but that was of course a pretty dangerous and undocument path.
And the Windows API only started to support the determination if a path is actually a symbolic link with GetFileAttributes() in Windows 7 and then checking that the return value is NOT EQUAL to INVALID_FILE_ATTRIBUTES and the flag FILE_ATTRIBUTE_REPARSE_POINT is set. And since Windows Vista there is an API CreateSymbolicLink() to create a symbolic link to a file or directory, but still none to create a junction point. For that you need to call directly into the Windows NTFS kernel driver. And there is also no way to query the path a symbolic link points to other than by calling into that NTFS kernel driver too.
The CreateFile() function used to open files will normally simply open the target file, unless you pass a special flag to it. The returned handle can't really be used to read and write to the symbolic link as it doesn't really have any content but can be used to pass to the kernel device driver for query of the path.
All in all it is still a somewhat murky implementation. Some file functions operate on the target file, others operate on the symlink unless the moon happens to be in an undetermined phase all in an attempt to make existing applications work with symlinks even if they don't know anything about them.
And to add insult to injury it is still a bad idea to use symlinks for redirecting your user directories to another partition because a Windows update will then fail with very weird behavior.
Basically LabVIEW needs to add an explicit check to the Delete function if the path is really a symlink and if that is the case then it needs to call the DeleteFile() function on this path without checking if the actual directory is empty. But that likely has some possible drawbacks in certain corner cases, so that the Delete icon might need to get an extra parameter input to instruct the function to operate on a symlink instead of the target. And then that means updating the code for Mac and Linux too to support this parameter and suddenly you talk about a several man weeks project for something that if Microsoft had supported it 20 years ago, it would simply have been included in LabVIEW then.
Only one kudo can be given hu? Thanks for the very detailed explanation. I was aware of some of this, since I remember using junctions in Windows PE 1.0 environments to minimize ram drive sizes by mapping to a read only part of a CD, but didn't realize how half complete the functionality was back then. So instead of calling this a bug, this sounds like it really should be an idea exchange, to ask that symbolic links have more support, which may mean waiting until Windows has their act together, or implementing somewhat hacky solutions. I'll just make a few wrapping subVIs that handle this through the system exec since for now my scope is limited to Windows.