File Dialog fails to show if start path is a non-existent UNC share

[jpdrolet]

LabVIEW 2020

When assigning Start Path to an UNC share that does not exist (like \\notaserver\notashare\...), the file dialog fails to show and the node exits with cancelled==TRUE and Error 43.

As expected, the file file dialog shows when Start Path is a non-existent drive letter so it is certainly a bug for UNC paths.

I have circumvented the issue by checking if the share exists before feeding it to the File Dialog node.

Jean-Pierre

[billko]

---

@jpdrolet wrote:

LabVIEW 2020

When assigning Start Path to an UNC share that does not exist (like \\notaserver\notashare\...), the file dialog fails to show and the node exits with cancelled==TRUE and Error 43.

As expected, the file file dialog shows when Start Path is a non-existent drive letter so it is certainly a bug for UNC paths.

I have circumvented the issue by checking if the share exists before feeding it to the File Dialog node.

Jean-Pierre

---

This is designed and expected behavior.  This is so you can catch malformed paths that were built programmatically.  I haven't seen any official discussion on why it returns a "43 user cancelled" error, but I'm guessing they did this because a cancel would result in an invalid path, so why not use the same error so you don't have to handle two errors that mean exactly the same thing.

So LabVIEW did its job and so did you.  🙂

[jpdrolet]

The path is not ill formed, it is a legit UNC path that points to a share that doesn't exists. Any other path to a file/folder that doesn't exist will open the dialog to the longest stripped path that exists, to the desktop or the last viewed directory.,.

From the help documentation for Start Path:

---

Path of the directory whose contents LabVIEW initially displays in the dialog box. If start path is valid, but does not refer to an existing directory, LabVIEW strips names from the end of the path until the path is a valid directory path or an empty path. If start path is invalid or unwired, the last directory viewed in a file dialog box initially appears in the dialog box.

So the error 43, cancelled is NOT the intended behavior described in the documentation.

[billko]

I've been doing more digging since you adamantly claimed this is a bug, and now I am inclined to agree with you.  Something about UNC paths doesn't work right.

[rolfk]

But it does. It may not seem intuitive but while UNC paths are an integral feature of the Windows NT kernel names space, the kernel can’t rely on built in facilities to deal with them. Instead it has to relay their handling to whatever network technology is used, traditionally this was NetBEUI, later it changed to NDIS and since a few years it’s NDIS5. Trying to verify network paths is slow even if they exist and terrible if they don’t exist, since the caller generally just has to wait until the underlying network driver times out. The Windows file dialog is part of the Windows shell layer, which lays several levels above the NT kernel which then has to redirect to the network layer for anything other than syntactical parsing of a path. LabVIEW simply uses that standard file dialog with very little customization of its own

Of course LabVIEW could try to second guess the error codes it receives from the file dialog and do some extra reinterpretation of its own when the file path is an UNC path (which it knows since UNC paths are a distinct path type internally in LabVIEW) and consider also the current moon phase and the overall operators mood in its decision, but it did try that in various places in the past, resulting in very complicated code that was pretty much unmaintainable in the long run but often had to be revised with every new Window version since Microsoft “improved” the API behavior.

That it returns a cancel error rather than a path does not exist error is a minor problem. I would be very concerned if would not return any error! Relying on specific error codes usually is a flowed idea anyways. If you want to know if a function failed because the path is not valid you should first explicitly check for that path validity and that it really exist, not rely on some function that often is layered 16 levels deep in the OS to return a specific error code. On the next systems, the driver 12 levels deep may be different and cause a different error to bubble up through all those layers!

[jpdrolet]

Hi Ralph,

Long time no see. It is a pleasure to argue with you again.

It is a bug because:

1. It is a file dialog node. The file dialog should pop in spite of whatever invalid, non-existent start path it is fed with. It does with one exception: inexistent network share.
2. When it fails, it returns a cancelled by user error which we can't discriminate from a legit cancellation from the user. That is not a minor issue; it prevented the user to modify a path in use in my application. The previous, now non-existent path was input to File Dialog and that triggered the issue.
3. The File Dialog, once opened, manages an inexistent share when it is filled in the file field. It reports Windows cannot access the share with Diagnose/Cancel buttons. It means the file system can handle this situation deep down in its layers.

How to circumvent it:

1. Don't use the start path. It means more click for the user to select the destination path.
2. Filter against all UNC path. It avoids the time required to check if a network path exists.
3. My take: Check if the path exists and strip the path until a path exists or an empty path. This is exactly what the node is supposed to do according to the documentation.

On the other hand, when network timeouts are an issue for file access, I check first the server by opening TCP connection to test ports 138 or 445 which are used for windows file sharing. I set a short timeout for the connection, shorter than the usual large timeout for native file access. I start file operations after I know the server accepts connections.

[rolfk]

But there is a very specific problem here. While it is not ideal as it is, there is a fundamental problem if you pass in a non existent UNC path. That issue is related to the documented behaviour of an invalid local path.

"If the passed in path is invalid, the function will strip a path element from the path until the path is a valid path!"

That works since LabVIEW has a notion of the canonical empty path mapping to the virtual root of all disk volumes.

Great then just move up there! Nope! UNC paths have no common container. Explorer kind of makes it appear as if they were also just part of the "This PC" container but that is a hack of the Windows shell that Explorer really is part of.

This didn't exist at the time the LabVIEW file functions were implemented and LabVIEW choose the pretty novel approach of creating a virtual top level container that would combine all the drive letters. At that time the Microsoft solution to accessing the file system was called File Manager, which was not even remotely as complex and involved as the current Windows Explorer. The entire Windows shell is tacked together with all kinds of plugins based entirely on COM and navigating programmatically through that virtual namespace is an exercise in mental acrobatics, exceptions and super exceptions of exceptions on how to treat specific containers.

The LabVIEW developers never choose to try to mimic that, partly because that whole shell interface was considered secret by Microsoft until they were forced by a court to document it because of anti-competitive considerations.

Even if they did, you would end up in the container that contains disk drives only or LabVIEW would need to find a way to discover what network shares your Explorer shell knows about and these kind of things are to the day of today not really documented, but require reverse engineering techniques, that the LabVIEW developers always tried to avoid at all costs.

So basically naively argumented you are right it is a bug, but effectively even if they "fixed it" you would simply end up at the LabVIEW canonical file system root, which only knows about mounted disk drive letters.

As to checking for network resources to try to avoid timeout delays, that's a very nice theory, but in the case of the Windows File Dialog pretty useless. The Windows File Dialog is a black box. It allows to pass in things like what path to start in, if you want to select a file or directory and some minor customizations as to what buttons and other UI elements to display or not and then it pretty much ends. How it tries to resolve network paths is hidden in there, and some levels deep. As application you have to either live with that or make your own file dialog and live with the criticism of most users that the dialog looks so terribly non-standard.