Mac OS - network file access

[WNM]

I am a long-time Windows guy who has built a LabVIEW application used by many in my organization for searching a networked datafile.  I am trying to get that same application built for the Mac OS with the help of a colleague who does use a Mac and is getting started with LabVIEW on it.  We have had some success with it working, but only if the server location containing the datafile is mounted locally on the Mac and then accessed from that local location.

Under Windows, the functional file path used by the program to find/use the networked file is this:

   \\nfssvc0008\pdx\home0\gl_pdx_prod\Data.xls

On the Mac, it doesn’t let us enter the full path to mount the drive and load the file -- the VI is rejecting the double forward slashes, instead replacing them with a single forward slash.

   smb:/nfssvc0008\pdx\home0\gl_pdx_prod\Data.xls

     vs.

   smb://nfssvc0008\pdx\home0\gl_pdx_prod\Data.xls

How should the path be specified to the remote file from the VI such that local mounting of the volume is not required?

Thanks!

[WNM]

It turns out that for the Mac OS, the acceptable path element "slash" separators lean a different direction from those used in Windows. No doubt some organization wanted to set themselves apart with the difference. That difference meant that a Windows path constant, control or indicator will not accept a Mac OS path without first mangling it into something that won't later work on the Mac OS.  The solution was to use text strings to contain the paths that are appropriate for each system with the proper string selected by a conditional selector that is sensitive to the OS in use.  The string-to-path conversion function turns the selected string into a usable path for the given OS.

[WNM]

After some testing on a Mac we discovered that the string-to-path function strips out the double forward slash delimiters that are used as part of the "smb://" that identifies the device as a network drive and replaces them with a single slash so that it looks to the LabVIEW open-file function like we are trying to open a local device/folder/file that does not exist.

Interestingly enough, the path appears to the Mac OS as a clickable link when in a document, and as such, it can be clicked and will cause the file on the server to open so it seems it is more akin to an HTML link than a file path. 

We are now investigating a call to the "System Exec.vi" function and it looks like, with this command, open 'smb://nfssvc0008/pdx/home0/gl_pdx_prod/' it opens a locally mounted volume gl_pdx_prod that points to the proper server folder, which can then be used with this LabVIEW path: Volumes:/gl_pdx_prod/Data.xls to access the file.

It would have been more useful if LabVIEW had a way to do this like on Windows without having to jump through these extra hoops of opening a local volume but this is at least workable.

[rolfk]

LabVIEW file paths are just that: file paths. The \\server\share\path\..... syntax is called an UNC name and is really only a Windows feature that LabVIEW has extra support added to in order to recognize it but that support only exists on Windows platforms. The special support is mostly present in TextToPath routine since the \server\share\ can not be separated and needs to be treated as a single path component just like C:\ for a local drive path. The Windows file functions can directly work with these UNC paths.

The MacOS X Posix file API that LabVIEW uses nowadays on all Unix like platforms has absolutely no knowledge of UNC. Some command line tools tolerate the Unixified UNC syntax //server/share to mean the same as /server/share but that will only work if you have created a mount point in your local file namespace to the actual server resource. The format you are using is an URL format and only would work when interfacing to high level Cocoa APIs in the NSFileManager namespace, except that Apple likes to introduce and a few versions later depreciate APIs like it is peanuts to rewrite your software every few years. It’s absolutely not and especially changing anything with file paths and file handling is a major pitta to change in an existing software!

There is a small change that you could call some Core Framework shared library functions to turn the URL in a path. LabVIEW comes with a library that already interfaces to some of these routines in vi.lib/Platform/ but this won’t be a quick drop in exercise. Some serious tinkering and reading Apple Docs is required.

[rolfk]

As an addition I would definitely try to solve that over the command line as much as possible unless you intend to write a general purpose library to reuse in other projects.

Trying to call Apple Framework routines is a frustrating exercise. The online documentation of functions can often at best be called sparse and when googling you will often come across promising functions only to discover that Apple has depreciated them a few versions ago. The depreciation state is not neccessarily the worst, it basically means that Apple has marked the function as not recommended for use in new programs and that there is a real chance that it may simply disappear in a future version of Mac OS X. The really bad thing in my view is that Apple is not only very diligent to mark those functions as depreciated in their online docs, but simply removes even the already sparse documentation right away so you can only guess what the function parameters are meant to be used for unless you try to find old copies of the online doc on the web.

Trying to program in anything but ObjC or recently Swift is going to have you always run into the depreciated wall at some point with often no valid options other than to try to use the depreciated function anyhow or create some code in ObjC to export the functionality to non ObjC. But even in ObjC space APIs get regularly depreciated.

[WNM]

Hi Rolf,

Thanks for sharing your expertise in this area.  You say:

  "I would definitely try to solve that over the command line as much as possible unless you intend to write a general purpose library to reuse in other projects."

and by "that", I assume you mean:

"There is a small [chance] that you could call some Core Framework shared library functions to turn the URL [into] a path. LabVIEW comes with a library that already interfaces to some of these routines in vi.lib/Platform/ but this won’t be a quick drop in exercise. Some serious tinkering and reading Apple Docs is required."

And you then go on to say:

"Trying to call Apple Framework routines is a frustrating exercise."

and you give examples of how the framework is a constantly moving target that is difficult at best to use and rather unstable over the long term as Apple seemingly has trouble sticking with a basic set of functions.

So, given all that, how is it that you say using the framework preferred over using the command line?

[rolfk]

It’s a trade off really. Developing a library is a lot more work but if you intend to reuse it on different systems and make it available for use to others it can be a more integrated looking solution.

The command line is quicker but overall more brittle. If you need to make it work on a lot of different machines you are more likely to run into problems that it won’t work on some machines due to various reasons such as OS version, specific installations, user rights, locale settings and such.

So it really depends.

[WNM]

Thank you, I understand perfectly what you are saying. But since:

1. the original goal was to make this one application, used by a large Windows community within my organization, also available to a smaller Mac community
2. the Mac community (or the Windows community, for that matter) within the organization is tightly constrained to only used the most recent versions of their respective OS's. This application just needs to work for a very small, well defined audience that shares a common organization network for access to the one data file.
3. I do not have the Mac experience or a Mac development system and my associate, who does have those (and has agreed to do some simple testing for me) does not have the LabVIEW experience or the available time within his work assignment to figure out the more integrated solution.

I think that the command-line solution may be the more practical direction.  As for the command line solution being more fragile, at least the "System Exec.vi" interface to it from LabVIEW is likely to be stable and, as my associate said, "Mounting volumes isn’t something that Apple is going to be changing anytime soon. It’s core Unix, not something they’ve built on top."  

As much as I'd like to be the one to provide a comprehensive fix for the combined shortcomings of the MacOS and LabVIEW in this area and share that fix with the LabVIEW community, I'm afraid that a comprehensive fix is beyond my capabilities or needs at this time and I'll just have to content myself with shining a bit of a light on the problem and saying this is not how these products should work together.