Long paths suddenly broken on Windows 11 Dev Instance
I have been running Acumatica 22r1 and 23r1 instances on my Windows 11 Pro work computer for months. Tonight, I tried to publish my 23.110.0025 project, and I suddenly started getting errors with the path being too long. It appears that on the 16th (2 days ago) Microsoft pushed out a Windows Configuration Update which I suspect is the culprit.
Error:
e2023-09-19 02:12:09.674] Patching the file C:\Projects\SSCS_23_110_0025\Customization\SSCS_23_110_0025\SSCS_23_110_0025Validation\SSCS_23_110_0025Website\CstPublished\Pages_SS\SSCS1000.aspx.cs
e2023-09-19 02:12:17.038] System.Exception: An error occurred while copying files to the temp directory ---> 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.Directory.InternalCreateDirectory(String fullPath, String path, Object dirSecurityObj, Boolean checkHost) at System.IO.Directory.InternalCreateDirectoryHelper(String path, Boolean checkHost)
Can anyone else confirm this problem or know a solution? I found old threads stating that Acumatica ERP cannot be installed on Windows 11, which was incorrect until this weekend. I also found posts describing how to enable long path names in group policy and registry settings.
Registry
regedit
Navigate to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
set LongPathsEnabled to 1
Group Policy
gpedit
Navigate to Computer Config, Adminstrative Templates, System, Filesystem
Set Enable W32 Long Paths to Enabled
Page 1 / 1
According to my research, the long paths issue is much older than Windows 11, and probably dates back to the beginning. However, the problems was solved in a roundabout way in recent versions of Windows.
According to this article Windows 11 seems not to respect the long paths settings.
Have you looked if this setting is enabled?
Have you determined what path is too long? This path is only 149 chars:
Great observation! I didn’t even think to count the length on that. I’m not sure what the next file/folder is. My assumption is that it must have gone into a “next step” and THAT file/folder is too long for whatever reason.
I got this particular naming convention from an ISV friend, and I really like it as it has helped me contain and manage different versions and installations. This worked great until this weekend, but I don’t know how to troubleshoot at this point, so I can’t really tell you what the “next” attempted path is. Would love some insight into how to do that.
According to my research, the long paths issue is much older than Windows 11, and probably dates back to the beginning. However, the problems was solved in a roundabout way in recent versions of Windows.
According to this article Windows 11 seems not to respect the long paths settings.
Have you looked if this setting is enabled?
It talks about the 2 options I detailed at the end of my question, so yes I set those and rebooted. Please advise if I missed something in the post that I should check.
One thing you could try is to look through the Event Viewer application that comes with Windows. I expect you’ll see some errors in the Application log:
You can find the approximate time the issue occurred and possibly get a bit more information about the actual error that occurred according to Windows (since it is a Windows error).
I am running on Windows 11 and have never had any issues, but my paths may be shorter, I’m not sure.
@Brian Stevens
Just wondering if you code file (C:\Projects\SSCS_23_110_0025\Customization\SSCS_23_110_0025\SSCS_23_110_0025Validation\SSCS_23_110_0025Website\CstPublished\Pages_SS\SSCS1000.aspx.cs) has any code(file/folder reference) that could lead to the error?
RESOLVED
No luck in event viewer, but I published on my old DEV instance which my sysadmin had upgraded to 23.110 as well. Interesting that they both get through the same list of files. My local instance complains of filename too long where the server hosted DEV instance states on that same line “Done”.
I did find a workable solution (for now), but I don’t like it as I’m not certain how likely it is to rear its head again as I continue the root cause activity…
Jump to the bottom if you want to skip the bulk of how I got there
My local instance with full stack trace in the error
r2023-09-19 15:36:13.747] Patching the file C:\Projects\SSCS_23_110_0025\Customization\SSCS_23_110_0025\SSCS_23_110_0025Validation\SSCS_23_110_0025Website\CstPublished\Pages_SS\SSCS1000.aspx.cs s2023-09-19 15:36:26.445] System.Exception: An error occurred while copying files to the temp directory ---> 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.Directory.InternalCreateDirectory(String fullPath, String path, Object dirSecurityObj, Boolean checkHost) at System.IO.Directory.InternalCreateDirectoryHelper(String path, Boolean checkHost) at Customization.CstSyncWebsiteFolder.SyncDir(String src, String dest) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 215 at Customization.CstSyncWebsiteFolder.SyncDir(String src, String dest) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 306 at Customization.CstSyncWebsiteFolder.SyncDir(String src, String dest) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 306 at Customization.CstSyncWebsiteFolder.SyncDir(String src, String dest) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 306 at Customization.CstSyncWebsiteFolder.SyncDir(String src, String dest) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 306 at Customization.CstSyncWebsiteFolder.SyncDir(String src, String dest) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 306 at Customization.CstSyncWebsiteFolder.SyncDir(String src, String dest) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 306 at Customization.CstSyncWebsiteFolder.SyncDir(String src, String dest) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 306 at Customization.CstSyncWebsiteFolder.SyncDir(String src, String dest) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 306 at Customization.CstSyncWebsiteFolder.SyncDir(String src, String dest) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 306 at Customization.CstSyncWebsiteFolder.CopyFilesInternal(String sourcePath, IEnumerable`1 files) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 114 at Customization.CstSyncWebsiteFolder.CopyFiles(String sourcePath, IEnumerable`1 files) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 78 --- End of inner exception stack trace --- at Customization.CstSyncWebsiteFolder.CopyFiles(String sourcePath, IEnumerable`1 files) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\WebsiteFolder.cs:line 89 at Customization.CstManager.ValidateDocument(CstDocument doc, ICustomizationLogger logger, Boolean patchLibInDB) in C:\build\code_repo\NetTools\PX.Web.Customization\Global\CustomizationManager.cs:line 260 at PX.Customization.CstValidationProcess.ValidateCurrentDocument(ICustomizationLogger logger, String& projectNames) in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\CstValidationProcess.cs:line 378 at PX.Customization.CstValidationProcess.CompileInternal() in C:\build\code_repo\NetTools\PX.Web.Customization\Publish\CstValidationProcess.cs:line 227 t2023-09-19 15:36:26.445] An error has occurred. Please report this error to the technical support and attach the information provided above.
Keep in mind that while my hosted dev instance is called DEV and my local dev instance is called SSCS_23_110_0025 (thus making my local path much longer) - the local instance worked fine last week, and as Daryl pointed out, the displayed file/path is far less length than the long filename cap reported in the error, so this must be getting copied in full to some other “temp” folder in preparation to replace the live website.
SOLUTION - BUT NOT IDEAL
Now for the really interesting discovery… First, I tried altering the “CustomizationTempFilesPath” in web.config on the site so that it is much shorter.
Was (default per my instance name): <add key="CustomizationTempFilesPath" value="C:\Projects\SSCS_23_110_0025\Customization\SSCS_23_110_0025" />
After setting to “Tried” and refreshing my browser before publishing again, I checked both paths for number of files using a tool called TreeSize Free. I found that I have a lot more files in the shorter path than the longer path. More interesting, I found FrontEndSources went from ~15k files to over 20k files. This got me thinking… the other thing I have been doing in the last week is trying to start shelling in Modern UI (typescript) screens. That process apparently creates more files than what I started with, and the resulting files apparently are too long with the path under my long naming convention to work with the “copy”.
I went for broke and set to the “Now” shown above, and it published. The file/folder length is THAT close to the cap from “Tried” to “Now”.
So the issue here stems from the website being copied during publication, and the Modern UI development generating a LOT of files under that folder structure that result in very long path and file names. If you aren’t working on the Modern UI yet, you likely won’t see this. Once you do, WATCH OUT! This might rear its ugly head for you as well, depending on if your instance name is somewhat long like mine.
Got past that hurdle - post on that pending review. I thought the project would publish now, but no. It progressed on to a new error in a section I have never seen before. Then again, I started working on building the Modern UI last week (to get a jump on it, but not to be enabled in production.)
Are you using VS Code? The post I referenced above specifically mentioned VS Code being problematic.
Actually, if you’re doing new UI stuff, have you attempted to publish something in a different instance not related to the new UI?
Have you looked at this post? You could be the first to post in the new #dev-new-ui Discord channel
Are you using VS Code? The post I referenced above specifically mentioned VS Code being problematic.
Actually, if you’re doing new UI stuff, have you attempted to publish something in a different instance not related to the new UI?
I use Visual Studio, not VS Code. Also, I published the project in our company DEV instance fine, presumably because the instance name is shorter than my local instance name.
The root cause is very long path names created under FrontEndSources compounded with my long instance name. The timing was coincidental to the updates from Windows Update. I started working on creating Modern UI screens to get a head start, but the plan was to leave dormant by not enabling in production. Unfortunately, “getmodules” and “build” under npm created thousands of file path/names exceeding the max path length of Windows 11 when validating during publishing.
In the end, it took:
ensuring my Modern UI files are backed up (they are in my repository, so :check:)
delete/move the FrontEndSources folder out of the website
“Upgrade Website” using the ERP Configuration tool to replace the (now) removed FrontEndSources folder
Reset the customization temp folder in web.config (from my trial and error efforts to identify the issue)
Restore my custom Modern UI screen files under the FrontEndSources folder (from the repository)
DO NOT use node.js to build the Modern UI in this development environment. (build and test that in another instance for now or use a much shorter instance name)
Publish the customization project.
Going forward, at least for now, developing for the Modern UI will require working in a separate instance with a much shorter instance name to address the resulting very long directory names built under FrontEndSources. Then the raw files can be copied over to the main project as needed. I may rework my local development instance to shorten the instance name, and thereby shorten the constructed paths used during publication.
@Brian Stevens I had this same issue. After a boat load of time, I did exactly what you did. I created a directory on my root drive C:\S” and put the temp files in that folder.
Thank you for being on the leading edge of solving these issues for us. Your posts have helped so much!
I’m glad I am starting this after you have done all the work! Thanks!