Why does the name of my TEMP directory keep changing?


A customer liaison contacted the shell team with the following request:

Subject: Support case: 069314718055994

On two of my customer's machines, he's finding that if he opens %TEMP% from the Start menu, it opens C:\Users\username\AppData\Local\Temp\1, C:\Users\username\AppData\Local\Temp\2, and so on. Each time the user logs off and back on, the number increments. The number resets after each reboot. Why are we seeing these folders being created under Temp? This does not appear to be the default behavior. What would cause the operating system to create these folders?

The customer rebuilt one of the affected machines, and the behavior went away. However, the customer claims that both machines were working fine before, and then this problem suddenly started. Therefore, the customer is afraid that the problem will come back in the future. Any pointers in solving this mystery would be very much appreciated.

It's not clear why this question was directed at the shell team, since Explorer doesn't set your TEMP directory. (In general, a lot of random questions come to the shell team not because they are shell questions but because people don't know where else to turn. Since the shell presents the desktop, and the desktop is on the screen when the problem occurs, maybe it's a shell issue!)

The question was redirected to the Remote Desktop team, since it is Remote Desktop that creates these subdirectories off the TEMP directory. And from there, psychic powers predicted that the problem lay in the Administrative Templates\Windows Components\Terminal Services\Temporary folders group policy. If you don't select Do not use temporary folders per session, then these TEMP subdirectories are created. (Yet another of those crazy negative checkboxes.) There is also a knowledge base article describing the registry keys behind these group policies.

The customer liaison responded cryptically,

Thanks. I tested the policies and it is the one that creates the folder.

Not sure what this means for solving the customer's problem, but that was the last we heard from the customer liaison, so I guess this policy was enough to give the customer a nudge in the right direction.

Comments (25)
  1. frymaster says:

    "Therefore, the customer is afraid that the problem will come back in the future"

    what problem?  Why does it matter if the temp location jumps around anyway, it's temporary!

  2. Troll says:

    With IE protected mode, the temp directory when accessed from IE's open/save dialogs redirects to %tmp%Low folder which is extremely annoying because it's a low integrity process.

  3. asf says:

    Speaking of %tmp%Low, there is no KNOWNFOLDERID for this, so something that needs %temp% and is launched from LowIL IE is screwed!

  4. BOFH says:

    So which Registry value is it that controls this, is it "FlatTempDir"?

    Enabled = no more 1, 2, etc?

    [Use the Use separate temporary folders for each session group policy. The registry keys are provided only for informational/troubleshooting purposes. -Raymond]
  5. Danny Moules says:

    Why do I suspect the direction they actually took was informing their end-users to disable this functionality so they can continue to hard-code the temp directory against all good practice and sense? (I am, of course, assuming they are a software vendor…)

  6. This leaves unanswered the question of how the policy got set in the first place.

  7. Joshua says:

    I do have such a system that wants semi-hardcoded temp paths (actual location is a persistent config file). However, the system would be undisturbed with %temp% bouncing around.

    As for why one would want to fix %temp% has to do with making sure it gets cleaned properly. Junk files lying around waste disk space and sometimes provide unwanted information leaks.

  8. Jon says:

    Ah, I always wondered what the 1, 2's were.  I learned something new today :)

  9. Alex Grigoriev says:

    I don't know how that was a problem. The actual problem is that the darned programs drop the temporary files there and LEAVE THEM THERE. %TEMP% becomes a dirty dump. I suggest everybody to add a requirement to their software: When a process exits gracefully, it should not leave anything in %TEMP%. Especially those stupid installers.

  10. James Schend says:

    @frymaster: Hey they pay for the support, whether they have actual problems or not. Might as well use it to get some questions answered, right?

  11. George says:

    Thanks. In addition to the negative checkbox anti-pattern, the documentation of <i>Administrative TemplatesWindows ComponentsTerminal ServicesTemporary folders</i> contains this gem for "Using Group Policies (best practice):"

    To disable the creation of a separate temporary folder for each terminal server session, click Enabled. To enable the creation of a separate temporary folder for each terminal server session, click Disabled

    Feels like a usability anti-anti-antipattern.

  12. Joshua says:

    [Use the Use separate temporary folders for each session group policy. The registry keys are provided only for informational/troubleshooting purposes. -Raymond]

    Unfortunately very necessary to know when the domain controller feeds a broken policy that must not be applied.

    [Presumably that falls under "troubleshooting". -Raymond]
  13. Gabe says:

    George: That's quite a gem! It's hard to imagine nobody thought to write it this way:

    "To share a single temporary folder for all terminal server sessions, click Enabled. To create a separate temporary folder for each terminal server session, click Disabled."

    Then again, it's hard to imagine what sort of app requires the setting to be one way or the other.

  14. Malcolmm says:

    "To allow each user to share a common temporary folder across all interactive sessions (localy or via Remote Desktop), enable this setting. To allow each user's session (locally or via Remote Desktop) to have its own temporary folder, disable this setting. Either setting could solve some application compatibility problems, depending on whether they believe users always have the same temporary folder path (enable the setting) or whether they believe users always have isolated folder paths (disable this setting). Leave this setting disabled unless you identify a scenario where it needs to be enabled."

    I think that's a better explanation…

  15. Joe says:

    @Alex Grigoriev: Too many developers assume that %temp% is automatically cleaned by the system periodically. Heck, *I* assumed that for the longest time. Every time I found junk in there it was always "Well, I haven't rebooted in a long time" to explain away all the junk.

    I wonder why Windows doesn't automatically clean up its various temp folders on reboot? I can only assume there are a significant number of programs that keep non-temporary data there, so MS is stuck.

  16. Malcolmm says:

    "Then again, it's hard to imagine what sort of app requires the setting to be one way or the other."

    Badly written ones ;)

    For instance, applications which use fixed filenames for sort or temporary files, assuming TEMP will never be shared. Most would fail to start a second instance, as they couldn't open a second instance of the file with exclusive-write. They're the ones that need per-session temporary directories.

    The second class … apps which do interprocess communication via files in TEMP (even if only in the form of leaving set of results X for second application Y to pick up). Much to my annoyance, we have some apps (or rather, extensions to a CAD program) written like this at work. They at least use their own, separate, TEMP directories ….

  17. C:WINDOWSTEMP says:

    Sometimes users temp path got set to C:WINDOWSTEMP instead of the own temp folder. Usually when running web sites (iis).

  18. tenfour says:

    "a lot of random questions come to the shell team not because they are shell questions"

    because the shell team has the best problem solvers!

  19. David Walker says:

    Alex:  I have seen installers put DLLs in TEMP and then USE them from TEMP, forever.  So when you clean up your temp directories, things stop working.  This is horrible practice.

  20. jader3rd says:

    Sounds like their problems would have been solved by creating a folder under %ProgramData%.

    As for the assumption that %Temp% gets cleaned periodically, it's my understanding that it does get cleaned up when you run the Disk Cleanup utility. But these days our disks are so big, how often do you have to run it?

    Personally, I've come into situations where I wish NTFS has a Cleanup Date attribute on files, similar to Creation Date and Last Modified Date. Then when a disk is starting to run out of space the OS could scan for files past their cleanup date, and clean them up.

    [The problem, of course, is that apps which are guilty of leaking files into %TEMP% are also apps which will never bother setting the Cleanup Date. All you did was create more work for law-abiding people. -Raymond]
  21. Joshua says:

    Maybe Windows could use something like tmpfs. Declare 20GB of fixed swap, all %Temp% are mapped into a drive that lives in swap. Reboot = wipe all temp files.

    Is it gonna happen? No bloody way.

    [I'm sure you can see the compatibility issues this design would introduce. -Raymond]
  22. Ben Voigt [Visual C++ MVP] says:

    Since my %TEMP% is set to a ramdisk location, I have first-hand knowledge about the compatibility issues.  The biggest issue I've had is with an antivirus program that creates a temp file for each internet download… and stores a copy of the entire downloaded file, which occasionally exhausts space on the ramdisk.  Miscellaneous other issues from permissions not being identical to the original directory created by Windows.  None that I know of from the temp directory getting wiped at reboot.

  23. LR says:

    @Joshua:

    Some programs save data in TEMP which could become important when the program crashes. I think, MS Word used to be one of them: It was able to recover an unsaved document, provided that some auto-save option was enabled in Word's settings beforehand.

    Lotus Notes lets you open documents directly from an e-mail, by shell-executing a copy of the attached file, saved in %TEMP% under a new, unique name. When you are working on such an document, without too much thinking, your modified copy is still in %TEMP%. You better have no auto-cleanup in place if your system reboots as long as your modified file is still there. Otherwise, you can easily lose hours of work.

    My disk at work is filled by 50 GB out of 1 TB => There is really no need for nasty scripts.

  24. Joshua says:

    Good point LR. Curious how software intended for use by programmers doesn't exhibit that behavior.

  25. Stefan Kanthak says:

    @Ben Voight:

    | None that I know of from the temp directory getting wiped at reboot.

    I suspect that your %TEMP% points to a drive letter different from %SYSTEMDRIVE%. Since MoveFileEx() doesn't work across drive letters installation/replacement of locked files during reboot works for your setup … by accident.

    If you want to see installations which use MoveFileEx() fail just "mount" your RAMDISK to %SYSTEMROOT%TEMP (this is where the SYSTEM environment variable TEMP points to) and remove all your users/administrators TEMP environment variables.

    @C:WINDOWSTEMP:

    Services (like IIS) run under system accounts which dont have a user-specific %TEMP% and therefore use the system-wide %TEMP%

Comments are closed.

Skip to main content