Skip to main content
Solved

Long paths suddenly broken on Windows 11 Dev Instance

  • 19 September 2023
  • 12 replies
  • 830 views

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

  1. regedit
  2. Navigate to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
  3. set LongPathsEnabled to 1

Group Policy

  1. gpedit
  2. Navigate to Computer Config, Adminstrative Templates, System, Filesystem
  3. Set Enable W32 Long Paths to Enabled

12 replies

darylbowman
Rank
Badge +12

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?

Daryl ⚡Contract Acumatica Developer (MVP🏆) for hire ⏩ linkedin.com/in/darylbowman
darylbowman
Rank
Badge +12

Have you determined what path is too long? This path is only 149 chars:

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

 

Daryl ⚡Contract Acumatica Developer (MVP🏆) for hire ⏩ linkedin.com/in/darylbowman
B
Rank
Userlevel 6
Badge +4

Have you determined what path is too long? This path is only 149 chars:

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

 

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.

Changing the world, one byte at a time - https://bstevens.net/ (formerly acumatica.dev)
B
Rank
Userlevel 6
Badge +4

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.

Changing the world, one byte at a time - https://bstevens.net/ (formerly acumatica.dev)
darylbowman
Rank
Badge +12

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.

Daryl ⚡Contract Acumatica Developer (MVP🏆) for hire ⏩ linkedin.com/in/darylbowman
RohitRattan88
Rank
Userlevel 7
Badge +4

@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?

B
Rank
Userlevel 6
Badge +4

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

[2023-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
[2023-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
[2023-09-19 15:36:26.445] An error has occurred. Please report this error to the technical support and attach the information provided above.

 

My server locally hosted instance

[2023-09-19 15:34:52.456] Patching the file C:\Program Files\Acumatica ERP\Customization\AcumaticaDEV\DEVValidation\DEVWebsite\CstPublished\Pages_SS\SSCS1000.aspx.cs
[2023-09-19 15:34:52.582] Done
[2023-09-19 15:34:52.584] Validating Binary Files
[2023-09-19 15:34:52.961] Validating Sql Scripts
[2023-09-19 15:34:53.587] Validating the website C:\Program Files\Acumatica ERP\Customization\AcumaticaDEV\DEVValidation\DEVWebsite
[2023-09-19 15:34:53.589] IIS APPPOOL\AcumaticaDEV
[2023-09-19 15:34:55.928] Building directory '\WebSiteValidationDomain\App_RuntimeCode\'.
[2023-09-19 15:34:55.997] Building directory '\WebSiteValidationDomain\Controls\'.

 

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" />

Tried: <add key="CustomizationTempFilesPath" value="C:\Projects\bstmp" />

Now: <add key="CustomizationTempFilesPath" value="C:\A" />

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.

Changing the world, one byte at a time - https://bstevens.net/ (formerly acumatica.dev)
B
Rank
Userlevel 6
Badge +4

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

 

Changing the world, one byte at a time - https://bstevens.net/ (formerly acumatica.dev)
darylbowman
Rank
Badge +12

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?

Daryl ⚡Contract Acumatica Developer (MVP🏆) for hire ⏩ linkedin.com/in/darylbowman
darylbowman
Rank
Badge +12

Have you looked at this post? You could be the first to post in the new #dev-new-ui Discord channel 😉

Daryl ⚡Contract Acumatica Developer (MVP🏆) for hire ⏩ linkedin.com/in/darylbowman
B
Rank
Userlevel 6
Badge +4

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:

  1. ensuring my Modern UI files are backed up (they are in my repository, so :check:)
  2. delete/move the FrontEndSources folder out of the website
  3. “Upgrade Website” using the ERP Configuration tool to replace the (now) removed FrontEndSources folder
  4. Reset the customization temp folder in web.config (from my trial and error efforts to identify the issue)
  5. Restore my custom Modern UI screen files under the FrontEndSources folder (from the repository)
  6. 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)
  7. 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.

Changing the world, one byte at a time - https://bstevens.net/ (formerly acumatica.dev)
Joe Schmucker
Rank
Userlevel 7
Badge +3

@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!  😊

 

Joe Schmucker, CPA

Reply


Terms & ConditionsCookie settings