TMP vs TEMP: Why Windows Keeps Both Variables

If you’ve ever spent time digging through your Windows environment variables, you’ve likely stumbled upon the classic redundancy: both TMP and TEMP exist, and they often point to the same directory. It feels like a mistake, a relic of poor planning, or just another layer of Windows cruft. But if you’ve ever wondered which one actually dictates where your applications dump their junk, the answer is frustratingly simple: it depends entirely on the application.

Here’s the reality that most developers miss: there is no single "correct" variable. The existence of both is a direct result of the chaotic evolution of MS-DOS and early Windows development. In the early 80s, there was no standard. When MS-DOS 2.0 introduced piping, the system needed a place to store temporary files. The authors of COMMAND.COM chose TEMP. Meanwhile, other developers, working in a vacuum of documentation, independently decided TMP was the more logical choice.

This created a split that never truly healed.

The Legacy of Inconsistent Standards

Because there was no central authority enforcing a standard, the industry fractured. Some programs checked for TEMP first, while others prioritized TMP. Many developers, realizing the mess they were in, wrote code that checked for both, but the order of operations was entirely at the whim of the original author.

This next part matters more than it looks: Windows eventually introduced the GetTempFileName function. If you are writing a modern Windows application, you should be using this API. When an application calls this function, the underlying system logic typically prefers TMP over TEMP.

Why This Still Matters Today

You might think this is just ancient history, but it creates real-world headaches for system administrators and power users. If you are setting up a build server or a restricted environment, you cannot simply set one and forget the other. If you only define TEMP, a legacy application or a specific toolchain might ignore it entirely because it’s hardcoded to look for TMP.

Here is the practical approach to handling this:

1. Always define both variables.
2. Point them to the exact same directory path.
3. If you are writing your own software, use the standard Windows API functions rather than reading environment variables directly.

Here’s where most people get tripped up: they assume that changing one will automatically propagate to every process on the system. That isn't how it works. Environment variables are inherited at the time of process creation. If you change these values in your system settings, you must restart your applications—or even your entire session—for the changes to take effect.

Why does this fragmentation persist? Because breaking backward compatibility is the cardinal sin of Windows development. Removing one would break thousands of legacy tools that have been sitting in production environments for decades. It’s the "Adidas versus Puma" of the computing world—two competing standards that refuse to die.

If you are currently troubleshooting a disk space issue or a permission error, check both. Don't assume that because you cleared out the folder pointed to by TEMP, you’ve actually cleaned up the system. You need to verify where TMP is pointing as well.

Are you still seeing applications writing to unexpected locations? Check your user-level variables versus your system-level variables, as the former will often override the latter. Read our guide on managing environment variables effectively to ensure your configuration is bulletproof.

Understanding the history of TMP vs TEMP saves you from chasing ghosts in your system logs. Keep them synced, use the proper APIs, and stop worrying about which one is "right." Try this today and share what you find in the comments.