LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
JonathanLindsey

Remove File Path Length Limitation

Status: New

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.

12 Comments
wiebe@CARYA
Proven Zealot

Where doesn't it support long paths? E.g. how do you notice this limit?

Intaris
Proven Zealot

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....

KiwiWires
Member

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. 

wiebe@CARYA
Proven Zealot

The few times I had problems with long paths (with GIT IIRC), a subst command helped, effectively replacing the long path with a short path.

 

I had no problems with LabVIEW itself and long paths.

 

Of course LV FPGA and RT should not have problems with long paths, but that sounds more like bug fixes than a new feature?

iwane
Member

Hi all,

 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).

 

I haven't tried adding options to the LabVIEW manifest file, as mentioned here: https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#enable-long-paths-in-windows-10-...

Maybe this helps...

Piotr F.
Hardware Engineer @ ZF
wiebe@CARYA
Proven Zealot

>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.

iwane
Member

> 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.

 

There is a KB on path length: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015AHaSAM&l=pl-PL 

It states that whatever's supported by the OS, should be supported by LabVIEW...

Piotr F.
Hardware Engineer @ ZF
wiebe@CARYA
Proven Zealot

>There is a KB on path length: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015AHaSAM&l=pl-PL It states that whatever's supported by the OS, should be supported by LabVIEW...

 

That makes this a bug?

iwane
Member

That makes this a bug?

 

Not certainly a bug. It might be a design decision not to support this - we don't know until NI R&D states this clearly.

 

A limitation - for sure. OS allows something, but LabVIEW limits the usage to a more or less arbitrary limit.

Piotr F.
Hardware Engineer @ ZF
AristosQueue
Proven Zealot

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. 🙂