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.
I have run into this problem with IPcores for Xilinx code. Xilinx is used a lot on Linux machines where such limitations don't exist and they are prone to generate files within directories with large HASH values attached tot he names. I've frequently run into problems by having my Xilinx files in directories too "high" up the hierarchy on my HDD. I now try to keep them as close to the top.level of my repositories as possible. So much so that the location of my Xilinx support files and the code that uses them are no longer even remotely the same.
For me, I would love this problem to be fixed, but I don't know if all of the programs reliant on it automatically benefit or if they need to be programmed to take advantage of it....
I hit a file path limit during deployment of a DCAF application to a cRIO. I had to rename the repository and some module paths to shorter names. It doesn't help that this company's default SVN repo location is C:\Users\KiwiWires\Documents\Work\123 Some Project\trunk\..... rather than C:\SVN\...
I think I have hit it during TestStand deployments as well.
So more of a compile issue for me than an UI / app issue.
I definitely support the idea. If the OS supports long paths, why should I revert to workarounds (like mentioned subst command) instead of taking full advantage of underlying OS features?
I had a problem with Application Builder - I have a nested directory structure in the project. When build was run by a GitLab CI runnner (in an even deeper path), it failed - as soon as the path to the file to be generated reached 255 characters. Shortening the path helped, enabling long path in Windows registry did not help - effectively narrowing the problem to LabVIEW support for long paths. The value also points at LabVIEW, as Windows itself should support 260 characters before failing (without long paths enabled).
>If the OS supports long paths, why should I revert to workarounds (like mentioned subst command) instead of taking full advantage of underlying OS features?
Because the workaround is available right now...
>I had a problem with Application Builder - I have a nested directory structure in the project. When build was run by a GitLab CI runnner (in an even deeper path), it failed - as soon as the path to the file to be generated reached 255 characters. Shortening the path helped, enabling long path in Windows registry did not help - effectively narrowing the problem to LabVIEW support for long paths. The value also points at LabVIEW, as Windows itself should support 260 characters before failing (without long paths enabled).
Sounds to me it could be GitLab CI, Windows, the command line in general, the Application builder (a module in LabVIEW), LabVIEW, or any of the connections between the parts.
Windows itself support 260 characters, but not all Windows applications do.
I feel a "available in NXG" coming up. It's probably not that easy to change this (if it needs changing) in the entire code base.
> Because the workaround is available right now...
That's what I've done - shortened the path, until the proper solution is available. Maybe better wording would be "why should I be forced to revert to workarounds".
> Sounds to me it could be GitLab CI, Windows, the command line in general, the Application builder (a module in LabVIEW), LabVIEW, or any of the connections between the parts.
Could be. However GitLab CI runner worked fine in checking out the project and Windows installation had long paths enabled in registry. The build failed in Application Builder - either run from LabVIEW CLI or by hand, by logging in to the affected machine and running a build manually on it.
Definitely not a bug. Just a feature that hasn't been added yet. Rebuilding and retesting LabVIEW for new capabilities of the OS is always a feature request, and this one has never garnered a lot of attention from customers. It affects surprisingly few customers.
> OS allows something, but LabVIEW limits the usage to a more or less arbitrary limit.
It is the OS that has that arbitrary limitation in all of its older APIs. We think it is a change we could make without breaking LabVIEW. It has come up a couple times in discussion over the last year. Wouldn't surprise me if this gets priority sometime in the next two years, but I don't set the time table for features like that. I put my personal kudos on the idea, but I've only been bitten by it twice in 20 years. Of course, one of those two times was April 2020, so the frustration is fresh in my mind. 🙂
