Windows 10 now handles long file paths although it has to be enabled with via various possible registry or group policy edits. Windows applications have to opt in. LabVIEW source code should be able to utilize long file paths.
No, it has not been added yet. This was sent to me by NI sales office today (7/20/2021):
The long path functionality has not been implemented for LabVIEW when using Windows 10.
Right now, the roadmap to include this feature on LabVIEW has not been implemented by our developer
NI claims to support Windows 10. I'd argue that "supporting Windows 10" includes long path name support. NI's documentation refers to issues with GIT repositories and long file names generated as a result. Perhaps as AQ says this "affects surprisingly few customers" but as UNC names/network shares and GIT repo usage picks up, more and more of us will get bit. Please add HM Electronics Inc. to the list of customers who desperately want this feature (long file name support) added. The idea that the OS will allow file and path names that are not valid inside the LabVIEW environment means IMHO that LabVIEW doesn't fully support Windows 10. File and path naming and the rules governing them are a critical part of any OS.
Of particular concern is sales statement that supporting long file paths isn't part of the roadmap... Future versions of Windows 10 will NOT require registry mods and application manifests to implement long file name support - it is going to be the de facto standard.
"I support gun control - as long as everyone is allowed to own a gun.". Sure.
Since LabVIEW 2021SP1 there is a setting in labview.ini
WindowsLongPaths=true
That should make long paths work in most locations in LabVIEW (but there might be some hidden corners that might not be prepared to handle such long names and cause new errors. Of course having this ini setting turned true by default would be nice. The Under Consideration might get changed to Under Development, by simply changing that default value in the LabVIEW source code. 😁
Even with this option on builds fails if a class's path is too long...
Of course, there's only a generic error messes (error 7 IIRC), without mentioning the file or the real problem...
Not sure if VI names are also a problem when building. I know for sure the class name was a problem. It was only 2 characters too long and was the fix and the problem was 100% reproducible.
Feels more like a bug than a missing feature nowadays...
Even with this option on builds fails if a class's path is too long...
I wonder about the exact circumstances. If the class name plus the vi name plus the library name and the : separators together are longer than 255 characters then it couldn't of course work. The path element has an absolute and non-modifiable limit of 255 characters. And the class name, library name(s) and vi name are all part of the same level in a path, so can't exceed those 255 characters in total.
If it isn't this limitation then it's most likely a limitation in some part of the build process. The path length limitation is a complex thing:
First there is the platform itself. Windows until a few years ago did not support long pathnames if you used the ANSII Windows API functions. The underlaying Unicode File functions can handle 2^15 - 1 character without problem, but the ANSI to Unicode translation layer did not, as the old classic APIs hadn't supported more than MAX_PATH anyways.
The LabVIEW file functions could have supported long path names since about 2000 if they had used the Unicode API even if they would not have supported Unicode otherwise in any way at that point.
With Windows 10 something, Microsoft removed the (by now artificial) limit to 260 character in the ANSI API, if and only if you enabled some obscure registry settings, most likely because there was a small chance that some Windows 3.1 executable could otherwise trip over its feet with long filename support.
At the same time NI added support for long filenames by interfacing to the Unicode file API instead, ca 2021 and the above mentioned ini setting enables that code path instead of going through the ANSII Windows APIs.
However, supporting long path names in the actual filenames, doesn't mean that every code path in the rest of LabVIEW will just suddenly and magically support it. It should of course if everything in LabVIEW itself was always done with its native file paths. And for LabVIEW tools that work platform agnostic, this is also the only sane approach. But, developers have a tendency to take shortcuts:
"Why convert this into a LabVIEW path element to add it to a LabVIEW path and then convert it back. Just do a printf() into a fixed size stack variable, with the text form and be done with it, saves us two conversions."
"But this won't work on non-Windows platforms!"
"Who cares, this tool is only ever gonna run under Windows anyways!"
So yes the WindowsLongPaths is NOT a guarantee that every part of LabVIEW will be able to deal with long paths. It only ENABLES the ability to deal with long paths with file operations, but still requires to test and verify every part of LabVIEW to actually not try to cut corners by doing some quick and dirty path formatting of its own but instead do proper path handling.
What I meant to say is this: The functionality is already there. In that sense it's a small effort to officially enable it. There still remains work to be done to test and verify that every part of the LabVIEW platform, even if there may be some obscure places sometimes, properly makes use of that LabVIEW file path handling and doesn't try to do its own shortcuts circumventing LabVIEW path handling somehow. This is unsexy and cumbersome work and the main reason that that INI token even exists.
It was the entire path, e.g. "e:\foo\..\bar\myclass.lvclass" that was too long. There wasn't an element in the path (no libraries) that was too long.
Changing the class's folder from \foobar\ to \foo\ reduced the path by 2 characters, and the problem was gone.
Using Subst to create a shorter path to the base folder would probably have worked too (e.g. "C:\my files\my projects\project x" -> subs -> "C\foo". Didn't try this time, but it worked in the past...
The build 'succeeds', but the result is a folder myexe.exe, in stead of a file myexe.exe.
Not exactly sure how the build process is constructed. But this basically means that the real LabVIEW part simply works. A LabVIEW built executable is basically a VI Distribution similar to a Source Distribution but with removed diagrams and front panels (where not needed) and then turned into a ZIP file with some header voodoo to make ZIP tools not recognize it as such, then calling the Windows resource management functions to embed it as a custom resource into the LabVIEW startup stub executable.
So basically the ZIP functions to turn the directory into a ZIP archive seem to stumble over the long path names! A real oversight in the long path support in MiniZIP implementation in LabVIEW that they simply took from the ZLIB library from zlib.net, although at the time it was put into LabVIEW, it was not yet hosted on zlib.net but already open source for a long time.
