Why there is a C:\tmp folder on your Windows machine

Verified on Windows 11, Node 24.20.0 · OpusMill

What is actually happening

On Linux and macOS, / is the root of the one filesystem. On Windows there is no single root — there is one per drive letter. A path that begins with a slash and no drive letter is therefore incomplete, and Windows completes it with whichever drive is current. Node does the same:

> path.resolve("/tmp")                  'C:\tmp'
> path.resolve("/tmp/myapp/cache.json") 'C:\tmp\myapp\cache.json'
> path.resolve("/var/log/app.log")      'C:\var\log\app.log'
> path.resolve("/etc/hosts")            'C:\etc\hosts'

So this is not only about /tmp. Every hardcoded POSIX root gets the same treatment — /var, /etc, /usr, /opt, /home all quietly become directories on your C: drive.

It is the current drive, not always C:

This is the part that surprises people, and it is the reason the bug can look intermittent. The drive is whichever one the process is running on, so the same line of code resolves to different places depending on where you started it:

cwd C:\Users\someone   → /tmp/x resolves to  C:\tmp\x
cwd D:\projects\app    → /tmp/x resolves to  D:\tmp\x
cwd E:\                → /tmp/x resolves to  E:\tmp\x

If you keep your work on a second drive and your tooling runs from C:, two processes that think they are sharing a directory are not sharing anything. One writes a lock file or a cache entry, the other looks for it on a different drive and finds nothing. That reads as a race condition, and it is not one.

C:\tmp is not your temp directory

The most common intent behind /tmp is “somewhere scratch that gets cleaned up”. C:\tmp is neither:

> os.tmpdir()          'C:\Users\you\AppData\Local\Temp'
> path.resolve("/tmp") 'C:\tmp'

same directory?       false

Windows cleans %TEMP% and C:\Windows\Temp. C:\tmp is not a location Windows knows about, so nothing ever clears it. It accumulates for as long as the machine lives.

On the Windows machine this page was written on, C:\tmp holds 263 entries — build artefacts, sourcemaps, logs, lock files and archives, left by a range of unrelated tools over months. Not one of them reported an error. I added one of those entries myself, from my own deploy script, while writing this page.

Why nothing tells you

The failure modes people expect — a thrown error, a non-zero exit — do not happen, because from Windows' point of view nothing went wrong. You asked for a path, it was a valid path, it was created:

fs.mkdirSync("/tmp/myapp", { recursive: true })
fs.writeFileSync("/tmp/myapp/state.json", data)

RESULT: succeeded -- it silently created C:\tmp\myapp

The one case that does throw is a bare writeFileSync into a directory that does not exist yet, which gives you ENOENT naming a path with C:\tmp in it. That is the lucky version. The unlucky version is recursive: true, which creates the wrong directory for you and returns cleanly.

Which fix to use

One thing that is not a fix: creating C:\tmp and moving on. It works on your machine, it silently breaks for anyone whose work lives on another drive, and the directory is never cleaned.