crelf Posted January 4, 2010 Report Share Posted January 4, 2010 Cross posted here. So I just tried a build in 2009 and got a curious error Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:Error 6 occurred at Create Folder in Create Directory Recursive.vi->AB_Destination.lvclass:Create_Destination.vi->AB_Build.lvclass:Create_Destinations.vi->AB_Application.lvclass:Create_Destinations.vi->AB_Build.lvclass:Build.vi->AB_Application.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller Possible reason(s): LabVIEW: Generic file I/O error. ========================= NI-488: I/O operation aborted. C:\Projects\VI Engineering\Software Products\1-09-xxxxx - VI Engineering - Hardware Explorer\Engineering\5 - Release\Executable\VIE Hardware Explorer\VIE Hardware Explorer.exe\LabVIEW 2009\user.lib\_VIE Internal Reuse Library\_vie_lib_dialog_&_user_interface.llb Due to operating system limitations, LabVIEW cannot create the folder because its complete path contains too many characters. The files that it's complaining about are going to be inside the exe, so why is it an issue? Surely the filename length check should stop at "C:\Projects\VI Engineering\Software Products\1-09-xxxxx - VI Engineering - Hardware Explorer\Engineering\5 - Release\Executable\VIE Hardware Explorer\VIE Hardware Explorer.exe", which is well under the Windows filename length limit, right? Even curiouser - changing the "Advanced" build option "Use LabVIEW 8.x file layout" seems to fix the issue... Quote Link to comment
Yair Posted January 4, 2010 Report Share Posted January 4, 2010 I posted a reply in the other thread (basically that the EXE is a ZIPped folder). I know that people who post to the NI forums aren't worth much, but it would be nice if you add the cross-post link to both posts . 1 Quote Link to comment
Black Pearl Posted January 4, 2010 Report Share Posted January 4, 2010 Filename length of original is 262 Chars, without root its 259 and according to http://en.wikipedia.org/wiki/Filename 259 is exactly the limit. When the builder now creates a temporary backup (postfixing with *.llb~) it would exceed the limit. Can you try how many chars you need to reduce to get rid of the error? Felix Quote Link to comment
hooovahh Posted January 4, 2010 Report Share Posted January 4, 2010 Even curiouser - changing the "Advanced" build option "Use LabVIEW 8.x file layout" seems to fix the issue... Nothing odd about that, I was just going to post that's your solution. Using the 8.x layout means it won't have sub folders within the EXE, which prevents you from hitting that all important 250-ish character limit in Windows. Quote Link to comment
crelf Posted January 4, 2010 Author Report Share Posted January 4, 2010 I understand why this is happening (LabVIEW is struggling with the filename length limitof temporary files during it's build) - but I still think that has nothing to do with me - shouldn't it just build somewhere further toward the root (in, say, a temporary location? These files are, afterall, temporary). Quote Link to comment
Saverio Posted January 4, 2010 Report Share Posted January 4, 2010 I know that people who post to the NI forums aren't worth much ... . Gee, thanks. 1 Quote Link to comment
Yair Posted January 4, 2010 Report Share Posted January 4, 2010 You're welcome. Quote Link to comment
crelf Posted January 4, 2010 Author Report Share Posted January 4, 2010 Hey hey your two - let's keep it civil. Saverio: I think Yair was being sarcastic. Quote Link to comment
Yair Posted January 4, 2010 Report Share Posted January 4, 2010 Actually, I was being ironic (although I need to check with Alanis to be sure). Quote Link to comment
PJM_labview Posted January 4, 2010 Report Share Posted January 4, 2010 This error 6 is actually a major pain in the behind when building executable in LabVIEW 2009. I think that LabVIEW should be smarter about it and detect when the path is too long and if necessary rename/relocate the offending VI(s) so it just worked. For most people this solution would be ideal. For people doing some more fancy stuff like calling VI dynamically by path in the build executable, a log file (containing the original and new VI name/path) should be created. At the very least, the error message should be improve to point the person attempting to build the executable in the right direction ("Generic file IO error" is really not descriptive enough). PJM Quote Link to comment
Saverio Posted January 5, 2010 Report Share Posted January 5, 2010 Hey hey your two - let's keep it civil. Saverio: I think Yair was being sarcastic. Well, yeah, I figured as much. I was being facetious. After all, I know he frequents the site you folks like to refer as to the "Dark Side". Quote Link to comment
hooovahh Posted January 5, 2010 Report Share Posted January 5, 2010 I was using VIPM once and had an issue with too long of a file path and it couldn't build the package. When I reported it to Jim his response was one that I should have expected. I don't remember the exact verbiage but it was basically that this character size limit should be handled by Windows first, and then if Windows doesn't handle it properly then LabVIEW should generate the appropriate error. He then went on to say that if Windows and LabVIEW both don't do any thing about it, then it was VIPM's responsibility to notify the user. With that response I accepted the fact that this bug is larger than just an application, and is larger than just a programming language, and that Windows should generate the appropriate error, which should propagate to LabVIEW. P.S. Sorry Jim if I butchered what you said, I'm going off of memory here. And I completelly agree that Generic File I/O not very helpful. Quote Link to comment
crelf Posted January 5, 2010 Author Report Share Posted January 5, 2010 I think that LabVIEW should be smarter about it and detect when the path is too long and if necessary rename/relocate the offending VI(s) so it just worked. For most people this solution would be ideal. Exactly. IMHO LabVIEW is having a problem during it's build, not me. LabVIEW created the issue by trying to do stuff out of bounds, not me. Sure, I can make changes to my code to work around the problem, but that's exactly what that is: a workaround, not a solution. I beleive this is a bug. Anyone from NI care to comment? Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.