Hi all,

I'm just detecting that UltraEdit is using a wrong directory for the temporary files while editing.
Rather than to store them in the %Temp% directory (that is actually D:\Temp), it stores them directly in C:\Windows directory.
Of course, since C:\Windows is a protected directory, they are "physically" stored in C:\Users\xxx\AppData\Local\VirtualStore\Windows, but even there, it is not where they should be.

I tried to add in uedit32.ini, in the [Settings] section, a line
Temp File Dir=D:\Temp
but this didn't change anything.

I'm 100% sure it was NOT the case in the past. But I don't know how long it's the case....
In particular, I have a VM (under VirtualBox) running a copy of my real machine, copy taken in November 2019, and in which one management of temporary files directory is OK.
In this VM, by default %Temp% is used, but if another directory is defined in uedit32.ini, it is taken into account.

I precise that I'm using a quite old version of UltraEdit : 15.20.0.1022, under Windows 10 Professional

Is this a known issue with recent versions of Windows 10, and is there a known fix?

Thanks in advance

PS: I just did a quick test with launching UltraEdit as administrator, the temp files are stored (actually/physically) in C:\Windows.

Hi Mofi,

thank you for your answer. It helped me to understand and to fix the issue.
Let me explain, since I guess it could be interesting for other users.

First of all, cleanse all temporary files, nor reset Uedit32.ini didn't give any positive result.

But I used your technique to open a command prompt, changed the tmp and temp variables and launch UltraEdit to run various tests.
And I discovered that if I was pointing these two variables onto any new folder I created for the test, it was working fine
On the other hand, if I let them empty, or pointing to a non-existent folder, contrary to your own test, wit UltraEdit 15.20, temp files were not created in %UserProfile%, but in C:\Windows (logically, and actually/physically in VirtualStore\Windows).


But if I pointed them to D:\Temp, the issue re-appeared
What was wrong with this folder?

So I decided to delete it completely, then recreate it (and reboot the PC to be sure the new folder was taken into account).

And then, it worked fine

Afterwards, happy with this result, I finished customization of my (new) Temp directory, reassigning it a specific icon.... and this became enough to have again the issue !
I then understood : when you assign a specific icon to a folder (using the Property / Customize in Windows Explorer), it adds a Desktop.ini file in the folder...and set the +R attribute to the folder (if this attribute is not set, desktop.ini is not taken into account, and the folder do not show its specific icon).
To have this +R attribute actually DO NOT make the folder becoming read/only. You can continue to create / delete / update files and subfolders in it, but (maybe?) UltraEdit consider it erroneously, and due to this attribute, "imagine" it won't be able to create its temp files in it, and then switches to C:\Windows (i.e. to where it switches when var are empty or indicate a non-existent folder)
This is somehow a bug of UltraEdit. Maybe it is fixed in recent versions? What about v22.20? Can you do the test?

Since I was frustrated to do not be able any more to have my pretty icon for Temp directory (it looks like a "work in progress" panel), I did the test to create, inside the Temp directory, a specific Temp\UltraEdit subfolder (without +R attribute, of course), and it works.
And to be sure to do not accidentally delete this subdirectory, I tried to give it +S and +H attributes (system and hidden) : contrary to the +R, these two attributes do not prevent at all UltraEdit to use it efficiently.

To sum up : (At least in v15.20) The Temp File Directory for UltraEdit MUSTN'T have its +R attribute set, otherwise it is ignored by UltraEdit, and this whatever the way this directory is defined, either with TEMP and TMP environment variables, or with the Temp File DIR entry in Uedit32.ini file.

Strange, at least for your test with 15.20 because I had the issue on my two laptops, one with Windows 10 Pro and the other with Windows 7 Pro.
To be more specific, my version is 15.20.0.1022, French version. The.msi installer file has been signed on Friday, November 13rd, 2009, 17:09:18.

Maybe yours is another build? (Actually, surely, since I guess you do not use the French version. )

For v22.20, I'm less surprised : IDM has had a lot of time to fix the issue between both versions (and even, maybe, between build I use and yours?)

I just did a test (on a VM) with an old version 12.20a I kept in my archives (French version too, and 32-bit too) - same problem.

And I downloaded the latest v28 from IDM website, French again, but 64-bit this time, and the issue is gone... since the temp file is no more in %temp% but in %appdata%\...