You’d think that with the name TEMP, people wouldn’t expect it to be around for a long time


A customer had a problem with the Disk Cleanup wizard. The customer liaison explained:

The customer would like to know what locations the Disk Cleanup wizard removes files from. The custom is running Application Q. They had a previous incident where they incurred significant downtime because the Disk Cleanup wizard deleted files from C:\Windows\Installer and C:\Temp that caused their application to stop working. When will the Disk Cleanup Wizard remove a Windows update?

Okay, we can talk about how the cleanup of outdated Windows updates works, but holy crap did you say that Application Q stores critical information in the C:\Temp directory?

You cannot assume that any files in the Temp directory will exist for any significant length of time. The name Temp stands for Temporary. Temporary means not permanent. If your application puts critical files in the Temp directory, then it is just asking for trouble.

If you need a permanent place to store your critical information, try a subdirectory of the Local Application Data directory.

Okay, going back to the questions about Windows updates: The Disk Cleanup Wizard removes up a Windows update if it has been superseded by another update. For example, there may be a roll-up update that includes the original update.

But I doubt that's what made Application Q stop working. I bet it's assuming that files in a temporary directory have permanent storage duration.

Comments (56)
  1. Leonardo Herrera says:

    What is “significant”? Is there a rule?

  2. KP says:

    While I don’t remember the name of it now, I had a very similar experience many years ago. An application I regularly used stored essential files in %TEMP%. Both data and application files were stored there. Like the customer in your story I learned of this after manually deleting the contents of %TEMP%. Be assured I found a replacement for that application immediately, one that didn’t do something so boneheaded.

  3. Entegy says:

    I think the worst manifestation of this is leaving behind some MSI in Temp, said MSI gets cleaned, and then that app can’t update or uninstall because the MSI is now missing.

    1. Please get a clue, resp. inform yourself of the modified behaviour of the Windows Installer (in part due to some changes introduced with MS14-049; see https://technet.microsoft.com/en-us/library/ms14-049.aspx#ID0ESAAG): the full .MSI are cached in %SystemRoot%\Installer

      1. Unfortunately, Entegy is actually right. Apparently, InstallShield (or its vendor thereof) hasn’t got the memo yet, not to mention how strange their treatment of MSI is. The MSI is cached alright but the dumbass installer still looks at the temp position even though it doesn’t need it.

        Also, don’t restrict yourself to MSI. Back in Windows 98, I had problem installing Internet Explorer because its temp files got deleted after the installation was completed but before I get to restart. I delayed the restart because I needed to finish saving something which was taking long. But how did the temp files go? I don’t remember.

        1. 1. InstallShield as well as other CRAPWARE, which wraps .MSI in self-extractors (see “Executable installers are vulnerable^WEVIL (case xyz): …” on FD or BugTraq) and unpacks them to %TEMP% is the primary part of the problem: the workings of the Microsoft Installer, it’s cache etc. were known BEFORE they started to build their CRAPWARE.
          2. the .MSI copied to %SystemRoot%\Installer before some “defense in depth” changes had been stripped from their “MEDIA”, ie. the embedded .CAB(s) which include(s) the files to install: the Windows Installer reads the (meta)data of the .MSI ONLY from its cache, never from any of the historical locations of the .MSI recorded in the registry.
          This stripping but invalidated the authenticode signatures, and forces Windows Installer to prompt for the location of the ORIGINAL .MSI … which was long gone if some braindead self-extractor wrote it to %TEMP%.

          JFTR: Wintendo is DEAD! It had no automatic purging of %TEMP%. Many users but purged it a (re)boot from AUTOEXEC.BAT … and forgot to check whether there were pending renames present in WIN.INI.
          Windows NT executes pending renames during reboot, before someone can purge %TEMP%.

          1. Entegy says:

            What are you on?

  4. DWalker says:

    I have gotten yelled at by other people because, while doing them a favor and cleaning up junk on their computers, I have emptied the recycle bin or the “deleted items” folder in Outlook. One colleague used to keep valuable e-mail messages in the Deleted Items folder. Holy cr@p. I suggested that this is not a good idea.

    1. Boris says:

      That would not be the same, though. In the case of TEMP, you could reasonably make the argument that they couldn’t have known when the files would be deleted anyway, so it wouldn’t matter if it was you who did it, but in the two cases you mention, there are set expectations about the length of time between temporary and permanent deletion.

      1. DWalker says:

        For the e-mails, my colleague kept important e-mails in the Deleted Items folder for a long time. He COULD have created another folder, but no, he liked to use Delete Items for some reason. Weird.

        1. TBF, there’s a handy default shortcut for “move this item to Deleted Items” in Outlook. If you don’t know that it’s possible to set up your own shortcuts, then I can see how it’d make sense to use Deleted Items as a storage spot. as it’s just Ctrl-D to move items to “safety”.

  5. alegr1 says:

    The Microsoft Installer being a world’s worst and slowest Unzip, if you clear C:\Windows\Installer, you will not be able to uninstall (and maybe even repair) applications. What a fragile pile of dung.

    1. What a COMPLETELY clueless $&%§!
      %SystemRoot%\Installer is the repository of the Windows Installer. A user^Wadministrator stupid enough to mess with the contents of thir directory gets what s/he deserves!

      1. Brian_EE says:

        Stefan,

        I am sure you could make your point without the use of ad hominem attacks, which are expressly against the ground rules for commenting on this blog. https://blogs.msdn.microsoft.com/oldnewthing/20040221-00/?p=40523/

        1. I’m sure that your interpretation just shows your state of mind!

          1. David Totzke says:

            Stefan:
            “I’m sure that your interpretation just shows your state of mind!”

            You mean sane of course.

            @Brian_EE is not alone in finding your comments unprofessional. You seem to have a familiarity and expertise in this area and I’m sure at least some of us could benefit from your insights. I doubt, however, that any of us have the time or the desire to wade through the rants to extract them.

      2. alegr1 says:

        Cleaning c:\Windows\Update is a troubleshooting step recommended by Microsoft when Windows Update gets hosed. Unfortunately, it also hoses the Windows Installer.

        1. Josh B says:

          There is no c:\Windows\Update, and if you mean %WinDir%\SoftwareDistribution, that has never had any effect on the installer in my experience. It’s valuable for fixing WU (and freeing up space) and benign otherwise, a rare and useful combination.

        2. JM says:

          @alegr1: the Windows update directory is C:\Windows\SoftwareDistribution (more specifically \DataStore and \Downloads), not C:\Windows\Installer. I very much doubt that any official Microsoft material recommends deleting C:\Windows\Installer, since this indeed destroys your ability to uninstall or update just about anything. This is something you only do if you’re absolutely desperate for space, you’ve already uninstalled everything you can uninstall and you basically don’t care about not being able to ever change or update your software anymore. Upgrading your hard drive, as big of a hassle as that can be, is probably still less costly.

          Deleting what’s in \SoftwareDistribution can indeed get a hosed Windows Update working again. This will remove your ability to remove already installed *updates*, but that’s far less serious since they rarely need to be uninstalled in the first place (and if you do need that, you’ve hopefully done it before throwing away \SoftwareDistribution).

        3. OUCH!
          C:\Windows\Update C:\Windows\Installer
          BTW: it’s %SystemRoot%\SoftwareDistribution

    2. Josh B says:

      If you delete the uninstaller you can’t uninstall things anymore? Who’d have thought it….

      And there’s a reason robmen’s blog name is “When setup isn’t just xcopy.”

    3. cheong00 says:

      Note that if you delete the database owned by the package manager of system’s choice from *nix system, it won’t be able to uninstall too.

      Are they also “a fragile pile of dung”?

      1. Ernie says:

        If I was into ‘semi-vulgar hyperbolic statements’ I could argue that one was a pile of dung collected from a number of monkeys hitting keys on a keyboard, while the other was a pile of dung resulting from cats resting on keyboards. Of the three (or maybe 4 yum!=apt) primary installers on desktop/server OS’s, NONE is a clear winner and each has issues when used in ways that are ‘against the grain’ of the intent.

        Speaking of TEMP, on some systems with large amounts of memory, I’ve seen temp exist fully in DRAM and at temperatures well over 0K. That makes it ‘extra volatile’.

  6. MC says:

    It’s a shame that %TEMP% isn’t purged more often. The PC I’m using here has files from January in TEMP. 6.3Gb in total

    Linux / Unix empties /tmp on each reboot, but that can be months or more on our production servers too.

    We had a database product that was creating unix domain sockets in /tmp then someone deleted them (being helpful and clearing out temporary files ) and brought down the database.

  7. 1. C:\Temp is neither any user’s %TEMP% nor the system’s %TEMP%; only CRAPWARE which ignores the 20+ years old “Designed for Windows” guidelines still creates C:\Temp!
    2. The disk cleanup wizard works on %TEMP% only: see
    [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Temporary Files]
    “Folder”=expand:”%TEMP%”
    For the documentation of the registry entries of the “data driven cleaner” see https://msdn.microsoft.com/en-us/bb776782.aspx
    3. The disk cleanup wizard also does NOT touch %SystemRoot%\Installer: only the Windows Installer fiddles with this directory.

    1. Antonio Rodríguez says:

      From reading the article, it’s evident that the user’s system is set up so that %TEMP% points to C:\Temp instead of C:\Windows\Temp . It’s not uncommon, and if the user (or the system’s owner) does it, it doesn’t violate any guidelines. I, myself, like to place the Temp folder in a different physical drive than the system partition is in. And, just being at it, I place the swap file there, too. I use to create a small (~8GB) FAT32 partition for that use (FAT32 is slightly faster in writing than NTFS). It makes the system more robust by reducing the chances that the system partition gets full, and also makes it faster when you need to swap out memory while opening a new process.

      1. Is this REALLY evident?
        Guess why %USERPROFILE% is NOT accessible for other (unprivileged) users?!
        Guess why a shared %TEMP% is a REALLY bad idea in the first place?!
        I love to exploit vulnerable contructs like these, they almost always allow an escalation of privilege.-P

      2. Placing %TEMP% apart from %SystemRoot% broke Windows Updates on Windows NT4 and Wintendo, where these placed the files they could not write to their final destination due to locks etc. in %TEMP%.
        See MoveFileEx()
        This was first corrected with a Service Pack in Windows 2000.

        “swap partitions” with FAT are “cargo cult”.-P

      3. Andreas says:

        Ever heard of SSD? Putting your pagefile on a FAT FS seems like an extremely insecure method of highly questionable merit. How many seconds per year do you think you have saved by making your system extremely insecure? There are all sorts of goodies in your pagefile: passwords, admin processes and other nice things. Since FAT doesn’t do ACLs it would be trivial to not only read your pagefile as a non-admin user but also modify admin processes in the pagefile to do a hacker’s bidding.

        In 2015 (soon 2016) the power of FAT is not its speed, it’s the ease of implementation because it has no security measures and no real fail-safe measures. That’s why it’s ubiquitous. But that’s also why you only use FAT for temporal insecure data, e.g. photos from digital cameras and such. Not for (what ought to be one of) the most secure files on your system.

    2. voo says:

      “1. C:\Temp is neither any user’s %TEMP% nor the system’s %TEMP%; ”
      And as we all know it’s totally impossible to change an environment variable to point anywhere else!

      But more serious, could you try a less confrontational and aggressive tone? It only comes across as unprofessional and childish and devalues any contributions you’re trying to make.

    3. Josh B says:

      C:\Temp is a nice short name for scratch space for command-lines, plus it’s not already full of %TEMP% junk. Nothing wrong with it for personal use, but I haven’t seen an application use it in at least a decade.

      Can’t help someone who mangles their environment though.

  8. Erik F says:

    It’s a good thing Application Q doesn’t run in Linux then, because they’d be in for a bad time writing files to /tmp which is usually a tmpfs partition nowadays (and thus basically a RAM disk!)

  9. Jimmy Queue says:

    Can you confirm, that the maximum amount of time I can expect i file to stay in a temp dir, is for as long as I have a lock from application on the file?

  10. Joshua says:

    I see MS finally got around to putting in something in Windows 7 and Windows Server 2008 R2 to deal with superseded updates about two years after I opened a support case due to repeated windows updates on Windows Server 2008 (not R2) causing the OS to exceed minimum disk space. Too bad it never got backported far enough.

    1. Windows\Installer does not hold Windows updates.

      They are placed in Windows\SoftwareDistribution and Windows\WinSxS. There are also some non-standard folders like Windows\CheckSur and Windows\GWX but I am sure you know why.

      1. %SystemRoot%\SoftwareDistribution is also volatile; WUAgent uses %SystemRoot%\SoftwareDistribution\Downloads\Install as private temporary storage to unpack downloaded .CAB and runs their payload from there, it is removed after every installation step.
        %SystemRoot%\WinSxS\[Install]Temp is used as private temporary storage for WinSxS.
        There a numerous other private temporary storages: DriverStore has one, Microsoft.NET another, …

  11. mikeb says:

    Sadly today – just one day after finding it – Bob can no longer get to \\scratch\temp\bob\xyz.exe

    Does anybody have a copy?

    1. David Totzke says:

      mikeb you win ALL THE THINGS :)

  12. alegr1 says:

    Worse yet, there are enterprise products that place a DLL they need to run to %TEMP%

    1. cheong00 says:

      Yup. Notable certain software that is similar to Outlook in a lot of way but runs Java instead of VBA.

      And worst, it won’t restore the DLLs in that location if you cleared the folder.

      I had to use their Web version just because I had cleaned up the Local\Temp folder many years ago.

      1. alegr1 says:

        Funnily enough, the DLL in question (some GCC-related library?) was watched by that (enterprise backup and recovery) package. If you rename it, it got quickly recreated. It was kept loaded, so you could not simply delete it. But you could set its ACL to prevent its loading, though.

    2. According to your definition “Windows Embedded POSReady 2009” must be an enterprise product.-(
      http://seclists.org/fulldisclosure/2012/Mar/17
      I really love this sort of backdoors!

      1. voo says:

        Putting dlls into %tmp% isn’t a backdoor – stupid yes (Although if they’re really temporary because say dynamically generated not even that), but perfectly harmless as long as you keep the default ACLs. Only the user herself and administrators should have access to a user’s temporary folder.

        1. As usual: kids who can’t even write their full name just babble.
          User access to files created and executed by an administrator is not harmless!
          Run an executable installer (say ROOTSUPD-KB931125.exe) that unpacks its payload to %TEMP%\ixp000.tmp\: the unprivileged user is able to modify the unpacked files between their creation and their use.
          See for a recent example.

  13. Evan says:

    Clearly Application Q is a weather monitoring program, and the authors thought that c:\temp was where it should store temperature readings. Of course it stopped working!

  14. Narr says:

    I can understand having ‘critical’ files in temp, temporarily while the program’s running, and then some scheduled task or OCD admin running disk cleanup, and the app goes to use the files and runs into an error that the developer wouldn’t expect.

  15. Um. There’s a group policy setting that causes Local Application Data to be deleted when the user logs out. This is used, for example, in a computer lab environment (such as you might find at a University, for example) where lots of people are sharing the same machine(s) and keeping all of the profiles isn’t realistic.

    So, depending on context, Local Application Data may not be the best choice either.

    1. voo says:

      The whole point of cleaning up the local application folder of a user is for the application to treat the user the next time just as if she was new on that machine. Data you really need should go into the roaming folder with all that entails.

      If the data you’re trying to store is required for the application to work at all it shouldn’t be stored in the app folder of a user but with the application itself (e.g. Things like dlls)

      1. Or in the ProgramData folder, if it needs to be writable.

  16. lol says:

    Good advice that makes the mistake of assuming enterprise security settings let users write files anywhere else.

  17. Rask says:

    I recall an incident back in the DOS days when I needed to free up some space on a friend’s computer. I did this by deleting the contents of the C:\Temp folder, and he nearly blew a gasket as he was using that folder for storage.

  18. jeffdav says:

    c:\windows\installer seems like a bad place to store your files as well.

  19. Robert Tassarone says:

    Three issues with your post:

    1. You’re conflating file criticality and file permanence. Critical does not imply permanent.

    2. With respect to data an app might store in a temp folder, it is entirely possible that the data is for example some state information that if deleted by surprise out from underneath the application then there could be data corruption etc.

    3. C:\temp is not an operating system folder unless it’s %temp% which I suspect in this users case it was not. I doubt the user expected the dial cleanup wizard to touch non-OS folders.

    1. EMB says:

      1) Nitpicker is nitpicking… Also, You are assuming that you have more info on this problem than Raymond have.
      2) You are assuming that info that is not delivered in the post was not omitted for simplicity
      3) You are assuming that info that is not delivered in the post was not omitted for simplicity and that you have more info on this problem than Raymond.

  20. Ian says:

    I think the use case for people moving things to the Recycle Bin/Trash, temporary directory, or Outlook Deleted Items and then expecting them to be there when they look again later is quite common: It is for files/emails that they might want again but probably won’t, but they most certainly don’t want to have to clean them up themselves. They take the risk that in the case that they do want them again, the computer won’t yet have deleted them, but blame it on the computer if they are deleted.

    Anyone who can invent an algorithm that can determine which files the user is happy to have deleted permanently without needing to consult the user would be onto a winner.

  21. James Curran says:

    I’ve always said one shouldn’t have a TEMP folder (particularly on a shared file system), but instead a TEMP72HR and a TEMP2MON folders. Everything in the Temp72hrs folder that’s more than 72 hours old can be freely deleted by anyone in need of disk space. Similarly with the TEMP2MON after 2 months.

Comments are closed.

Skip to main content