Specified path, file name, or both are too long ErrorLocked

Nevermind, fixed the issue. The version folders were too far away from the wybuild project file.

Yeah, unfortunately Windows has a path limit (250 or so characters) that is a remnant of early design decisions. Of course they support "long paths" but it's not easy to use.

It is a goal of ours to support long paths in the future (for both wyUpdate and wyBuild).

Can I ask how you fixed the issue? I encountered this one today too.

The way to fix this issue is to keep your path lengths reasonable (i.e. under 250 characters).

How do we find out which file it is that is causing the unhandled exception? Surely if I can add the file to the project/version via the GUI, then I should expect it to work? Can you add something that stops me adding this file, or otherwise allows me to work out which file(s) are causing this issue?

Are you using the AutomaticUpdater or wyUpdate as a standalone updater? What's the exact error you're getting? At what step in the process is the error coming?

I am using wyUpdate as a standalone updater.

I have a wyp file, and I have added my new version 1.0.12345 to the project. I then add all of the new files to it (which I have put in a new folder on my hard drive). This all works fine.

When I go to build the update from version 1.0.12344 to 1.0.12345, I get an Unhandled Exception, with the message details as in the original post (below too). The messagebox content is this:

"Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately.

"The Specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters."

Clicking "Details", gives this:

"See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. at System.IO.Path.SafeSetStackPointerValue(Char* buffer, Int32 index, Char value) at System.IO.Path.NormalizePathFast(String path, Boolean fullCheck) at System.IO.Path.NormalizePath(String path, Boolean fullCheck) at System.IO.Path.GetFullPathInternal(String path) at System.IO.FileInfo..ctor(String fileName) at wyBuild.Project.DiffRevisions(Revision oldRev, Revision newRev, Object[] oldRevDir, TreeNode newRevDir, String baseString, UpdateDetails updDetails, Boolean allowExBefore, SortedList[] deleteForCatchAll) at wyBuild.Project.DiffRevisions(Revision oldRev, Revision newRev, Object[] oldRevDir, TreeNode newRevDir, String baseString, UpdateDetails updDetails, Boolean allowExBefore, SortedList[] deleteForCatchAll) at wyBuild.Project.DiffRevisions(Revision oldRev, Revision newRev, Object[] oldRevDir, TreeNode newRevDir, String baseString, UpdateDetails updDetails, Boolean allowExBefore, SortedList[] deleteForCatchAll) at wyBuild.Project.DiffRevisions(Revision oldRev, Revision newRev, Object[] oldRevDir, TreeNode newRevDir, String baseString, UpdateDetails updDetails, Boolean allowExBefore, SortedList[] deleteForCatchAll) at wyBuild.Project.DiffRevisions(Revision oldRev, Revision newRev, Object[] oldRevDir, TreeNode newRevDir, String baseString, UpdateDetails updDetails, Boolean allowExBefore, SortedList[] deleteForCatchAll) at wyBuild.Project.DiffRevisions(Revision oldRev, Revision newRev, Object[] oldRevDir, TreeNode newRevDir, String baseString, UpdateDetails updDetails, Boolean allowExBefore, SortedList[] deleteForCatchAll) at wyBuild.Project.BuildUpdate(Int32 revisionFromIndex, Int32 revisionToIndex, UpdateBuilder updateBuilder, Boolean createCatchAll) at wyBuild.frmMain.BuildUpdate() at wyBuild.frmMain.btnBuildUpdate_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Loaded Assemblies **************mscorlib Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400) CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll----------------------------------------wybuild Assembly Version: 2.6.18.0 Win32 Version: 2.6.18.0 CodeBase: file:///C:/Program%20Files%20(x86)/wyBuild/wybuild.exe----------------------------------------System.Windows.Forms Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.5460 (Win7SP1GDR.050727-5400) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll----------------------------------------System Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.5456 (Win7SP1GDR.050727-5400) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll----------------------------------------System.Drawing Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.5462 (Win7SP1GDR.050727-5400) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll----------------------------------------Controls Assembly Version: 2.6.18.0 Win32 Version: 2.6.18.0 CodeBase: file:///C:/Program%20Files%20(x86)/wyBuild/Controls.DLL----------------------------------------System.Configuration Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll----------------------------------------System.Xml Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.5420 (Win7SP1.050727-5400) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll----------------------------------------Accessibility Assembly Version: 2.0.0.0 Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900) CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll----------------------------------------

************** JIT Debugging **************To enable just-in-time (JIT) debugging, the .config file for thisapplication or computer (machine.config) must have thejitDebugging value set in the system.windows.forms section.The application must also be compiled with debuggingenabled.

For example:

<configuration> <system.windows.forms jitDebugging="true" /></configuration>

When JIT debugging is enabled, any unhandled exceptionwill be sent to the JIT debugger registered on the computerrather than be handled by this dialog box."

Ok, you're right and we should warn you if your path is longer than 260 characters.

Is there any reason you're using such deep folder structures on your harddrive?

I wouldn't have said that they are particularly deep, but rather just structured.

We have them on d:\temp\projectname\branchname\wyupdates\version\

projectname is 3 chars, branchname (in this case) is 8, version is always 9 - but we just had a bunch of assets dropped and it seems that one or more of them take us past this limit.

Hmm, I thought I posted this earlier but it seems to have disappeared.

I looked into this some more, and the maximum length of the fully qualified path to any of my source files is 172 characters. Maximum length of the path relative to the project file is less than that. So it must be something else - are there any places I can look for application/temporary files that might have gone beyond this limit? I am completely blocked by this issue and I need to get it resolved, so any diagnostic information that you can think of, I am happy to send.

Well, a quick way to diagnose the problem (at least until we give a better error when this happens) is to narrow your project down to 2 versions. So, first copy your existing project. Then narrow the project down to 2 versions (where the problem is still happening). Then start removing files from each version (and rebuilding updates along the way. Then you'll be able to narrow down the problem to whichever files was causing the trouble.

Ok, I have done that and narrowed it down to one file.

I can't see how this issue is related to file paths, here is a list of the files I have in my project where I have a repeatable test case:

..\..\..\..\..\..\..\..\..\..\temp\fmo\internal\wyUpdates\client\1.0.296610\data\skins\fmo\style_sets\match_highlight_controls\live_highlight_button\button.xml..\..\..\..\..\..\..\..\..\..\temp\fmo\internal\wyUpdates\client\1.0.296610\data\skins\fmo\style_sets\match_highlight_controls\live_highlight_button\button_disabled.png..\..\..\..\..\..\..\..\..\..\temp\fmo\internal\wyUpdates\client\1.0.296610\data\skins\fmo\style_sets\match_highlight_controls\live_highlight_button\button_down.png..\..\..\..\..\..\..\..\..\..\temp\fmo\internal\wyUpdates\client\1.0.296610\data\skins\fmo\style_sets\match_highlight_controls\live_highlight_button\button_over.png..\..\..\..\..\..\..\..\..\..\temp\fmo\internal\wyUpdates\client\1.0.296610\data\skins\fmo\style_sets\match_highlight_controls\live_highlight_button\button_up.png

The issue is with button_disabled.png. It is showing up as read in wyUpdate, though it does exist on disk in D:\temp\fmo\internal\wyUpdates\client\1.0.296610\data\skins\fmo\style_sets\match_highlight_controls\live_highlight_button\button_disabled.png

As you can see, the relative file path length is 168 and the absolutely file path length is even less, 141.

If I delete button_disabled.png from the project and re-add it, it doesn't show up as red(invalid) until I close wybuild and restart it.

I played around with it and at best I can get it to work with a filename of 166/139 (relative/absolute) characters.

I mean, obviously it is related to file paths but what I meant was that I can't see/understand how it is related to the limits reported in the error message. We are some way off those, so it must be something internal, right?

I would be able to package something up (these files are very small) and send it to you in order to aid with debugging, if you like.

Yes, that would help. Send them to support@wyday.com and I'll take a look at it.

Any news on this?

Yes, this is caused by us combining the relative path "..\..\..\......etc." with the location of your project file "C:\Whever\"

That is, instead of truncating the "..\..\" and finding the clean path we simple combine the absolute & relative paths. Normally this wouldn't cause a problem. However, in your case this causes big problems because your project file and the files in the project are in very different folders and thus the combined path is much longer than 260 characters.

The quick fix (until we properly resolve the paths) is to put the wyBuild project file in the same folder (or "below") the files that will be in the project.

Does that make sense?

Yes, I will do that for now - thanks.

Any news on a fix for this?

Not yet, no.

Can I get an idea of the priority of this issue, please? We are nearing release(about 1 month) and if this isn't going to be fixed then I am going to have to start looking at alternatives.

Sorry, we weren't treating this as a priority problem because there's a good workaround. Namely, make sure the project file (*.wyp) is in a "parent" directory to the files.

For example:

Your project in "C:\Whereever\YourProject.wyp"And your app files in "C:\Whereever\Old Versions\..."

Does that make sense? Is there any reason why this wouldn't work for you?

It does work, but it is a nasty workaround which means I can't follow our defined project structures, so I have been using a temporary script/project and not submitting it to source control whilst I wait on the proper fix.

Ok, we'll bump up the fix priority and make a release early next month.

Hi,

Sorry to chase but you did say February...

Not yet -- we're pushing in a couple of features with this bug fix.

This month marks 1 year since we originally reported the issue, and there is still no sign of a fix. It has been 5 months since the last response; is there any further update?

It's still coming with the next update. Sorry for the delays.