Leaderboard

As Shaun already more or less explained it is a multilayered problem. 1) The LabVIEW path control has internally following limitations: - a path element (single directory level or filename) can be at most 255 characters. - the path can have at most 65535 levels The only practical limit that is even remotely ever reachable is the 255 character limit per path level, but I think we all agree that if you get that long path level names you have probably other problems to tackle first. 😀 (such as getting out of the straightjacket they for sure have put you in already). 2) Traditionally Windows only supported long path names when you used the Widechar file IO functions and also only when you prepended the path string with a special character sequence. LabVIEWs lack of native support for Unicode made that basically impossible. Long path names are limited to 32000 something characters. 3) Somewhere along the line of Windows versions (7, 8?) the requirement for the special character sequence prepending seems to have relaxed. 4) Since Windows 10 you can enable a registry setting that also allows the ANSI functions to support long path names. So while theoretically there is now a way to support long path names in LabVIEW on Windows 10 this is hampered by a tiny little snag. The path conversion routines between LabVIEW paths and native paths never had to deal with such names since Windows until recently didn't support it for the ANSI functions, and there are some assumptions that paths can't get more than MAX_PATH name characters. This is simply for performance. With a maximum fixed size you don't need to preflight the path to determine a maximum size to allocate a dynamic buffer for, that you then have to properly deallocate afterwards. Instead you simply declare a buffer on the stack, which is basically nothing more than a constant offset added to the stack pointer and all is well. Very fast and very limiting! This is where it is currently still going wrong. Now reviewing the path manager code paths to all properly use dynamically allocated buffers would be possible but quite tedious. And it doesn't really solve the problem fully since you still need to go and change an obscure registry setting to enable it to work on a specific computer. And it doesn't solve another big problem, that of localized path names. Any character outside the standard 7-bit ASCII code will NOT transfer well between systems with different locales. To solve this LabVIEW will need some more involved path manager changes. First the path needs to support Unicode. That is actually doable since the Path data type is a private data type so how LabVIEW stores path data inside the handle is completely private and it could easily change that format to use whatever is the native prefered Unicode char for the current platform. On Windows this would be a 16 bit WCHAR, on other platforms it would be either a wchar or an UTF8 char. It wouldn't really matter since the only other relevant platforms are all Linux or Mac BSD based and use by default UTF8 for filenames. When the path needs to be externalized (LabVIEW speak is flattened) it always would be converted to and from UTF8 to the native format. Now LabVIEW can convert its Path to whatever is the native path type (WCHAR string on Windows, UTF8 string on other platforms) and it support long path names and international paths all in one go. The UTF8 format of externalized paths wouldn't be strictly compatible with the current paths, but for all practical purposes it would be not really worse than it is now. The only special case would be when saving VIs for previous versions where it would have to change paths from UTF8 to ASCII at a certain version. I kind of did attempt to do something like that for the OpenG ZIP library but it is hacky and error prone since I can't really go and change the LabVIEW internal data types, so I had to define my own data type that represents a Unicode capable path and then create functions for every single file function that I wanted to use to use this new path, basically rewriting a large part of the LabVIEW Path and File Manager component. It's ugly and really took away most of my motivation to work on that package anymore. I have another private library that I used in a grey past to create the LLB Viewer File Explorer extension before NI made one themselves, and I have modified that to support this type of file paths. Works quite well in fact but it is all very legacy by now. But it did have long file name and local independent file name support some 15 years ago already with an API that looked almost exactly like the LabVIEW File and Path Managers.