LabView project file does not understand mapped directories

[Paul_Knight_Lockheed_Mart]

I have my LabView project file and VIs located on a network driver \\svr-maltese\botdfs which I have mapped to my S: drive.  I have a short cut that I use that gets me to

\\svr-maltese\botdfs\.....\48-000058-001-x01 or I can walk the S: tree down to 48-000058-0001-x01 directory, but I get to the same place and the same files.  Depending on how a get there I will be conficts that have to be manually resolved.  LabView does not seem to understand that they are the same file.  LabWindows has the same problem, but handles it better.

[smercurio_fc · Accepted solution]

They may be the same file, but they have a different path, so as far as LabVIEW is concerned, the hierarchy is different. I'm not sure what you're asking though. Are you asking for a confirmation, or are you requesting that something be changed in terms of LabVIEW's operation? If it's the latter, then you may want to post a suggestion in the LabVIEW Idea Exchange.

[Paul_Knight_Lockheed_Mart]

Just looking for confirmation.  If they fix it one day, ok. 

[rolfk]

Fixing this would be hard and quite costly in terms of performance. For each UNC file LabVIEW would have to query if it is on a network path and if there are alternate paths that also point to the same resource. Then it would have to normalize the paths. Networked file APIs in Windows are notoriously slow and hampered by all kinds of authorization problems where the only way to detect them is to start the operation and hope that it finishes properly, running into lengthy timeouts if it doesn't.

I doubt you would want LabVIEW to take one minute for every UNC file in a project every time you load that project because it does this alias checking and runs into network timeouts every time.

[Paul_Knight_Lockheed_Mart]

As I mention in my post, LabWindows also runs into this problem yet handles it in less than 30 seconds for a project with 10 files in it.  I am amazed how similiar LabWindows and LabView sometimes are, yet sometimes they do things completely different.

[rolfk]

I find 30 seconds for 10 files and in the case where your files are actually accessible under this path absolutely unacceptable. And it would for sure be more if the network was not available, since there would be typically a 30 or 60 second timeout per file access.