We're currently running LabVIEW 8.6 on a Windows platform, developing a package for a client who does not wish to upgrade (yet). This client has also mandated a directory structure for reports that can rapidly result in very long path names.
We have a modular architecture (of course), with paths passed between VIs using standard Path Controls.
We have created a support VI that will prepend the special string "\\?\" (as suggested by Microsoft) to enable a 32,767-character path to work on Windows. However, we still have problems:
We have discovered that a standard Path Control as provided by the Control Palette will truncate the path in it to 255 characters, regardless of what is displayed in the front panel control. I can't seem to find any information on how to change this or work around it. The only comment I've found anywhere is from this forum:
"LabVIEW paths have only a 255 character limit per path hierarchy level. This is because LabVIEW uses a Pascal String for each level."
It looks like I might have to change all the path controls to string controls and then do conversions. This is ugly and I'd rather pass paths around, but if the controls are going to truncate the fields it might be the only way.
Does anybody have any information or workarounds for this issue? Shorter path/folder names are not an option, I'm afraid.
What version of Windows are you running on?
Vista and Windows 7 support a NTFS Symbolic Link that you might be able to take advantage of.
You've probably already thought of this, but using a drive letter mapping may help shorten your path to < 255 characters...
net use x: "\\66021G1\c$\Documents and Settings\All Users\Application Data\National Instruments\TestStand 4.1.1"
You can then open a file in the Cfg folder using a name like x:\Cfg\stationglobals.ini
Windows 2000 and XP:
I know that hard links, junctions and simple shortcuts can't resolve to a remote computer using the UNC naming convention, but again if there is a long prefix that is constant in your file structure, you may be able to map a drive letter to that folder.
If the files are stored locally, there are a couple of utilities for creating a junction in Windows 2000 and XP, I used 'linkd' once for a specific problem...
We are using Windows XP as a platform. So is our client.
I should add that the upgrade from LV8.6 to 8.6.1 was the cause of much concern and discussion with our client, so upgrading is not really an option.
I have just discovered also that the TDMS Open function we are using will fail if the string is longer than 259 characters, even if it is prepended with the \\?\ string as suggested by MS. We may just have to document the limitation and live with it.
If shorter path/folder names are not an option and you're using Windows XP as your platform, I do not know of a current workaround regarding the 255 character limit per path.
What we've decided to do for now is to document the limitation in the user manual for the product and implement a function to check path lengths.
I was surprised to find that the TDMS Open function fails on a 260-character path name, even with the special prefix to allow 32,767-character paths.
Mind you, I was also surprised by the (seemingly undocumented) 255-character truncation of the Path control. Does LV 2010 fix this? Does LV 2010 fix the TDMS Open limitation?
What about LV2011?
I don't think TDMS Open has anything special operation for the file path, it just use the path which users supply and pass the path directly to some low level API.
I'm a little bit confused by what you men by \\?\, what does this mean? Do you have any steps to reproduce this problem? What do you expect TDMS Open do for the path? And did you try with some other file format?
That prefix only works when used with widechar Unicode Windows API functions. LabVIEW does use the ANSI variants so can't take advantage of this special prefix at this time.
I've run a couple of comparisons between LabVIEW 8.6 and LabVIEW 2010sp1 and have seen no difference in behavior. This is simply due to how LabVIEW internally parses/handles paths. I have not tested this in LabVIEW 2011 Beta but would not expect that this would change.
Windows (XP, and some other flavours) has a limitation of 260 bytes for a path name, normally. However, if you look up the MSDN website, there's an item about how to overcome this:
Basically, if you prepend the string \\?\ to a path, Windows should allow up to 32767 characters. For example, if the pathname "C:\My Long Directory String\Very Long File Name.Ext" was too long, adding the \\?\ to form the string \\?\C:\My Long Directory String\Very Long File Name.Ext should make the string work. For a server name of the form \\server\share\My Long Directory String\Very Long File Name.Ext, the format is slightly changed to become "\\?\UNC\server\share\My Long Directory String\Very Long File Name.Ext".
At least, that's the theory.
In practice, I've found that passing in any string of 260 characters or longer to TDMS Open will result in an error. A shorter string with the \\?\ prepended works quite happily.
I'd love to try with some other file format, but the system is coded to work with TDMS and modifying it to use another format is out of the question now.
Hi Rolf and Michael,
Thanks for the clarifications.
I've documented the issue in the user manual for the system now.
My next step is to implement a check (and warning) on path lengths when file names are created.
If 2010/2011 won't behave differently, we're just going to have to live with it.
I might also document the possibility of using the DOS "subst" command to shorten paths.