Check if File or Folder Exists.vi Returns TRUE with empty path input.

[Michael Aivaliotis]

It's nice to see that NI is "borrowing" some ideas from the community and including some functionality already available from OpenG. However, please do it right...

The function located here:

C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\utility\libraryn.llb\Check if File or Folder Exists.vi

Returns a value of TRUE when fed an empty path. .

[Jim Kring]

It's nice to see that NI is "borrowing" some ideas from the community and including some functionality already available from OpenG. However, please do it right...

The function located here:

C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\utility\libraryn.llb\Check if File or Folder Exists.vi

Returns a value of TRUE when fed an empty path. .

An empty path is the root folder (e.g., "/" on Linux). If you list the contents of the root folder (i.e., an empty path) on Windows and Mac, it will return the list of drives on the computer. So, technically, an empty path is a folder (directory) that exists. The OpenG VI (File Exists) works in exactly the same manor as the NI VI. However, the OpenG VI "Valid Path" does not return a TRUE, when an empty path is wired in. This is the VI that you should probably be using, first and foremost (instead of "Check if File or Folder Exists.vi") for checking if a path is valid.

That said, I can see your point about how confusing this is. Most LabVIEW developers are not aware of the fact that an empty path is the root folder/directory, by definition.

[Darren]

I wanted to add some File I/O Utility VIs to the palettes in LabVIEW 8.2 that would be helpful for all to use...and I didn't "borrow" that idea from anybody.

That being said, in my original version of Check if File or Folder Exists.vi, I did return an error on empty path. However, one of my fellow developers in LabVIEW R&D (a Linux guy, no less) filed a bug report against the VI because of the reason Jim described...empty path means "/" on Linux, "My Computer" on Windows, etc. So now the VI functions correctly in the technical sense. I will file a Documentation CAR against the VI so we can add a note to the online help that an empty path is considered a valid path, since it has definitely been a source of confusion (even for the author of the VI!).

By the way, Check if File or Folder Exists.vi will check the validity of paths to files inside LLBs...I'm not sure if the OpenG version of the VI does that...

-D

[Edit]: The LabVIEW Documentation CAR for this issue is 440CTMF2.

[crelf]

...empty path means "/" on Linux, "My Computer" on Windows, etc.

Which is why you should use "<Not a Path>" if you're really after something that's obviously not a path.

[Michael Aivaliotis]

Well, perhaps a future enahancement to this VI would be to have an additional output boolean: "not empty path". This way, a simple OR function on our part can provide the complete functionality most commonly desired in test systems these days. An empty path is usually not desirable and can cause systems to throw errors most of the time.

BTW, I didn't intend that my comment be an attack. It's just that it's really really wierd to see so many OpenG functions being duplicated within LV8.x.x. Perhaps it's just that NI's LV development team is noticing limitations in the current feature set just like we are.

[Jim Kring]

Since we're diving into the nitty-gritty corner-cases of the LabVIEW path data type...

I just learned that the Build Path primative allows appending an absolute path, when the base path input is an empty path.

This isn't stated in the context help, but the detailed (on-line) help states: "If base path is an empty path and name or relative path is an absolute path, this function sets appended path to the absolute path in name or relative path."

[Aristos Queue]

BTW, I didn't intend that my comment be an attack. It's just that it's really really wierd to see so many OpenG functions being duplicated within LV8.x.x. Perhaps it's just that NI's LV development team is noticing limitations in the current feature set just like we are.

No no. It's LabVIEW. We spent most of LV8.0 working on the underlying artificial intelligence. It now mostly writes itself. It has been generating libraries that it thinks it needs for some time now. By now, it should've generated all the library VIs that people on OpenG, NI, LAVA and DevZone combined could think of to write. Unfortunately, it sucks as an artist. Its icons are all text or plaid and its dialogs make a Linux command line seem user friendly. We'd let it ship more libraries, but it does take time to clean up the UI. That's really all we programmers do these days. Oh, and fix the text. LabVIEW decided that most human languages sucked and only deigns to speak to us in Esperanto. Since none of us speak or read Esperanto, we spend hours studying diagrams so we can rename the VIs as whatever it is that they do. It's not really arrogant, more like a teenager out to prove it knows more than its parents. Really, the only disturbing sign so far is the 200 node VI that took hours to puzzle out. It generates a stereogram that if you stare at it long enough displays the words "Hal9000 is my hero."

As a side note, LV's only comment when we asked it why it didn't have perfect automatic wire routing was, "The rat always complains about the path to the cheese. But the cheese is happy the path is not so direct."

[Ton Plomp]

"Hal9000 is my hero."

:worship: :worship:

Didn't know that I had so much in common with LV.

Is this the reason that LV 8 introduced itself as seperate Application Instances, so they can speak Esperanto with each other?

ne VIs kun erros

Now comes the Q:

what INI-key starts this mode?

Second (philosophical) Q:

Does LV sees itself as male, female or neutor?

Ton

PS Aristos, you made the sun come throught the clouds

[Chris Davis]

As a side note, LV's only comment when we asked it why it didn't have perfect automatic wire routing was, "The rat always complains about the path to the cheese. But the cheese is happy the path is not so direct."

Must have taken hours to translate that from Esperanto...

You guys should probably stop asking about the automatic wiring, LabView just might start password protecting all the diagram's it generates.