Your File System May Lack 8.3 Filename Support
Revised: 09/23/2023
Version: 8.x & up
If I logout and login again, that seems to resolve it. Disconnecting/reconnecting also seems to resolve it.
Any idea what's causing it?
Q - We get this error on a random basis.
Elliott SM Error from P2LVEFCT
Unable to create temp file:
C:\Users\202-CAP\AppData\Local\Temp\8\P2LVEFCT.501You file system may lack 8.3 filename support.Elliott will terminate.
If I manually create the directory (in this case, "8") it seems to resolve it in the current session.
Any idea what's causing it?
Click "OK", I get the following message:
No_8_3_FilenameSupport
A - This is what Elliott does. We ask the operating system (OS) for the location of the %temp% folder when we start up, and the returned path is “C:\Users\202-CAP\AppData\Local\Temp\8”. Based on that, Elliott attempts to create a temporary file named P2LVEFCT.501 in this folder to determine if it succeeds. It's crucial that we perform this operation during startup because when Elliott prints spooled reports, it stores temporary files in this %temp% folder. We assume that if the file can't be created in the %temp% folder, it's due to the volume lacking 8.3 filename support. However, this assumption is not definitive. We believe there are various possible causes, including but not limited to:
- The %temp% folder returned by the OS contains more than 65,525 (64K) temporary files, which would result in an error when trying to write to that folder. For more details, please refer to the following article: https://learn.microsoft.com/en-us/dotnet/api/system.io.path.gettempfilename?view=net-7.0
- It's also possible that the temporary path with the "8" in it does not exist. Why does the OS return a %temp% folder that doesn't exist? That's the million-dollar question here. We speculate that this may occur when the user remains logged in for an extended period without logging out, and the Windows OS removes the temp folder overnight. Somehow, either Windows or our system-level code still retains the old %temp% values, leading to this situation. The reason we speculate this is because we observed this happening during a deferred processing session where the user had been logged into the server for weeks without logging out.
- Another potential cause is that the volume lacks 8.3 filename support. Keep in mind that with the latest Windows OS, by default, volume D turns off the 8.3 file name format support. This become an issue when some users move their user profile (which contains the %temp% path) to the D: volume, possibly due to insufficient disk space on the C: volume, which could trigger this issue. For more details on this, please see the KB article: https://support.elliott.com/knowledgebase/articles/391841-elliott-requires-volume-supporting-8dot3name
For scenarios 1 and 2, if you log out of the Windows session and then log back in, the problem should be resolved. If the problem persists, consult the KB article in scenario 3 to verify if that is the root cause.
Elliott 8.6 Messages
The above sample screen applies to 8.5 behavior. If you are running Elliott 8.6, You may experience an error message (before 8.63.922 release) that indicate the temp directory name is invalid:
If you press "OK", then you get the following message:
After 8.63.922 release, the message is slightly changed.
EMK