LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

File Delete with Symbolic Link

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.

0 Kudos
Message 1 of 8
(6,090 Views)

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.

0 Kudos
Message 2 of 8
(6,077 Views)

@RavensFan wrote:

 

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.

0 Kudos
Message 3 of 8
(6,066 Views)

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 Smiley Happy 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.

 

 

Rolf Kalbermatter
My Blog
Message 4 of 8
(5,982 Views)

@rolfk

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.

0 Kudos
Message 5 of 8
(5,952 Views)

This has nothing to do with long path issues.  Please re-read this thread, it is about how LabVIEW Delete function won't allow for deleting symbolic links, but a command line del function will.

0 Kudos
Message 6 of 8
(5,190 Views)

Hi Hooovahh,

 

The message you were replying to is likely spam.  You'll see times where there are new members who's only contribution is mentioning that particularly tool.  If you google that name, besides the links that take you to the site, any legitimate discussion talks about what a spam/scam it is.

 

I've marked the message as spam to get it cleaned off the forums.

0 Kudos
Message 7 of 8
(5,181 Views)

@Hooovahh wrote:

This has nothing to do with long path issues.  Please re-read this thread, it is about how LabVIEW Delete function won't allow for deleting symbolic links, but a command line del function will.


Reported that last post as Spam too . But letting the admins here decide.

 

As to dealing with the original problem. you may be interested in a new release of the OpenG ZIP Toolkit that I'm still working on and finally getting to a state where I think I can soon release a test version of it. It has a full featured file management layer with among other things also Symlink support and Trash Can, is supposed to work for Windows. Mac and Linux and also supports long path names (up to 32k characters and all Unicode characters to, but on Linux only if it is configured to use Unicode UTF8 as locale).

 

Windows still is a strange beast there though. Creating SymLinks requires elevated privileges, unless you set it in some obscure developer mode in the Control Panel. Apparently SymLinks are very very evil and a great way to hack Windows.

 

And yes, to be able to support that long path names with arbitrary Unicode characters, I had to recreate every single File palette function that I was interested in to use. While it would have been relatively simple to add that support to the Path Manager in LabVIEW as far back as 20 years ago, and then all build in file functions would simply work with that.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 8
(236 Views)