Temp File Dir : Wrong directory used

Temp File Dir : Wrong directory used

7
NewbieNewbie
7

    Mar 14, 2021#1

    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.

    6,684586
    Grand MasterGrand Master
    6,684586

      Mar 15, 2021#2

      UltraEdit v15.20.0.1022 uses by default the directory defined by environment variable TEMP for temporary files. I recommend to run Disk Cleanup to delete all temporary files (and other files no longer needed). Temp File Dir=D:\Temp in [Settings] should also work. I have never seen that UltraEdit uses the Windows directory for temporary files nor has any user ever reported such a behavior.

      I opened a command prompt window, executed set temp= and set tmp= and started next from within this command prompt window UltraEdit v22.20. UltraEdit v22.20 used now with both environment variables for temporary files not defined the directory %UserProfile% for temporary files.

      What happens on renaming uedi32.ini in %APPDATA%\IDMComp\UltraEdit, for example, to uedi32.bak while no instance of UltraEdit is running and start next UltraEdit which recreates the INI file with everything set to default. Is it still using the Windows directory for temporary files?
      Best regards from an UC/UE/UES for Windows user from Austria

      7
      NewbieNewbie
      7

        Mar 15, 2021#3

        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.

        6,684586
        Grand MasterGrand Master
        6,684586

          Mar 18, 2021#4

          It's fine that you could solve the issue. I tried to reproduce the strange behavior on Windows 7 with UE v22.20 and also with UE v15.20. Both versions of UltraEdit create the temporary files in the configured directory even if the directory has read-only attribute set and contains the file desktop.ini with the icon resource reference.
          Best regards from an UC/UE/UES for Windows user from Austria

          7
          NewbieNewbie
          7

            Mar 18, 2021#5

            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%\...