LabVIEW
Path Type Primitive Incorrect Behavior
Solved!
Hello,
I would like to report that Path Type primitive wrongly handle relative path of type <drive>:<file>. Please see my example and this article: https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats
If my understanding is correct then the last example is not properly handled. Please confirm.
Hi Michael,
why do you blame the PathType primitive when StringToPath might be the real error source?
See this:
StringToPath "corrects" "C:…" to "C:\…"!
Hi Michael,
@bienieck wrote:
So, it means that String To Path have incorrect behavior.
Well, I would ask this question: since when does Windows support "C:abc\def" as relative path? I never stumbled across that in the last 25+ years I'm using Windows computers (or needed such a construct)…
You also need to keep in mind LabVIEW started as cross-platform IDE and StringToPath needs to work for different kind of OS in (mostly) the same way. Did Windows support such relative paths already in 1990?
I'm not claiming this might be a bug, but in case it is then NI will probably set this to very low priority. They usually don't change behaviour of a primitive after 20+ years… (They might update the LabVIEW help to warn you upon using this kind of relative path.)
Btw. MSDN says you can use this function to resolve the absolute path!
Edit:
BuildPath also doesn't care about this type of relative path:
("Dieser PC" translates to "C:\users\Gerd\".)
Even though the path to "Downloads\MathWorks" exists as shown in the Explorer path LabVIEW/BuildPath isn't able to construct that path from the absolute path to "Downloads" and the relative path "C:MathWorks" (without backslash)…
As a workaround you might build your own VI to resolve such kind of relative paths, acoording to all those examples given at MSDN:
// Setting current directory to 'D:\Docs'
// 'D:\FY2018' resolves to D:\FY2018
// 'D:FY2018' resolves to D:\Docs\FY2018
// Setting current directory to 'C:\'
// 'D:\FY2018' resolves to D:\FY2018
// 'D:FY2018' resolves to D:\FY2018\FY2018
Hi Michal,
@bienieck wrote:
It's irrelevant. I found inconsistency and reported it here. NI will do something with it or not. I need a workaround now anyway as long as I want to be consistent with the current MS documentation.
Posting this here in the forum will not start any action from NI…
You need to get in contact with NI and report that error. They will be happy when you send them your VI or even point to this discussion thread. Only then NI will examine this problem and eventually assign a CAR/bug tracking number.
You can also post a link to this thread in the bug tracking thread maintained by Christian here.
Yes Windows treats this path normally as relative path to the current directory for that actual Volume. But!!!!!
Current Directory on Windows is a totally flawed concept!!!!! That's not just because Windows is multithreading, where it is hard to define what the current directory should be if multiple threads try to access it. There is also the additional fact that Microsoft in its infinite wisdom decided that the platform file selection dialog should change the current directory to whatever you were in when you dismissed that dialog with anything else than Cancel. So there is simply no consistent current directory in any GUI application. Does it matter? You bet!
Will this be changed? I'm 99.9% sure that it will be closed as "Not solvable in a consistent way"! Aside that reporting it here will not trigger any action from NI. You need to report it through the official channels and get a valid bug report ID assigned for it. But as said, chances that this will be changed are pretty much non existent since there is really no consistent current directory concept on Windows anyways.
From https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getcurrentdirectory
Multithreaded applications and shared library code should not use the
GetCurrentDirectory function and should avoid using relative path names. The current directory state written by the SetCurrentDirectory function is stored as a global variable in each process, therefore multithreaded applications cannot reliably use this value without possible data corruption from other threads that may also be reading or setting this value. This limitation also applies to the SetCurrentDirectory and GetFullPathName functions. The exception being when the application is guaranteed to be running in a single thread, for example parsing file names from the command line argument string in the main thread prior to creating any additional threads. Using relative path names in multithreaded applications or shared library code can yield unpredictable results and is not supported.
This doesn't even cover the fact that there is no real API to access the current directory for a specific volume, so even if NI wanted to do this "right" they couldn't really do it without relying on some workarounds that screw with the multiplatform code as implemented now.
If you want this treated as the Windows documentation states (with all its possible flaws as mentioned above), you should call kernel32.GetFullPathName() for such a path yourself to get it resolved to the full path on a volume. It's easy enough to detect a path string to be a volume relative path and then call this function first to try to resolve it. Don't count on a consistent result however!
Relative paths SHOULD be ALWAYS converted to absolute paths explicitly before being passed to any function that accesses a system resource. Only your program really knows in what respect a relative path is meant to operate. Relying on the system to do that is a sure way for disaster rather sooner than later.
