File System Tunnelling: Why Windows Dates a New File Like a Deleted One

Picture this: you create a file, delete it, and then a few seconds later make a brand-new file with the same name in the same folder. You open Properties and Windows tells you that new file was created days ago. It looks like a glitch, but it’s actually a decades-old feature with a fun name: File System Tunnelling.

Here’s what’s really going on behind the scenes.

What Is File System Tunnelling?

File System Tunnelling is a feature of both the NTFS and FAT file systems. When you delete or rename a file and then quickly create another file with the same name in the same folder, the new file inherits metadata from the original — including its creation timestamp and the mapping between its long filename and its 8.3 short filename.

Microsoft’s FileSystemInfo.CreationTime documentation on Microsoft Learn puts it plainly: “NTFS-formatted drives may cache file meta-info, such as file creation time, for a short period of time. This process is known as file tunneling.”

So it’s not a bug. It’s a deliberate design, and it’s been in Windows for a very long time.

How File System Tunnelling Works

The mechanism relies on a temporary tunnel cache. When a file is deleted or renamed, Windows writes an entry into this cache. If you create a new file with the same name in the same directory within a tight time window — about 15 seconds — the cache hands over the old metadata to the new file.

The cache is per-volume, and it automatically clears older entries once it fills up. That’s why the effect is so fleeting: a new file won’t suddenly inherit an old timestamp just because a similarly named file was deleted last month. The timing has to line up.

Before privacy concerns creep in, note that the deleted file is truly gone. Its contents don’t resurrect. What Windows preserves for those 15 seconds is just metadata — the creation time and the SFN/LFN association.

IMG:1

The Quantum Analogy (Yes, Really)

Microsoft engineer Raymond Chen first explained this in a 2005 post on the Old New Thing dev blog. He borrowed the term from quantum mechanics, where a particle appears on the I can’t cross the energy barrier.

Chen joked that Windows’ file metadata pulled the same trick. In his words, “In the case of file system tunneling, it is information that appears to violate the laws of classical mechanics. The information was destroyed (by deleting or renaming the file), yet somehow managed to reconstruct itself on the other side of a temporal barrier.”

And there’s a delightful detail: the Windows 95 developer who built the feature got overboard with the analogy, naming the internal data structures quarks.

Why Microsoft Built It

Picture this: you edit a document you made yesterday and save it. You’d expect the file to keep its original creation date, because you edited it rather than created a fresh one.

But many programs don’t save in place. As Chen noted, “internally, many programs save a file by performing a combination of save, delete, and rename operation.” A program creates a temporary file with the updated content, deletes the original, then renames the temp file back to the original name. This is the safe save method.

Without tunnelling, that replacement file would show a brand-new creation date — even though, from your perspective, nothing new was created. In practice, this is why repeated saves through save-heavy applications keep their original dates rather than resetting to “today.”

There’s a second reason too. Older 16-bit applications only understood 8.3 short file names. If one replaced a long-named file without preserving the SFN/LFN link, the file could lose its friendly name entirely and revert to its DOS-era short name. Tunnelling keeps that association intact.

IMG:2

Which Operations Trigger Tunneling

Microsoft’s FltGetTunneledName documentation describes the per-volume tunnel cache and lists the operation pairs that can trigger it. According to the docs, these combinations can cause a file named “name” to be tunneled:

delete(name) / create(name)
delete(name) / rename(source, name)
rename(name, newname) / create(name)
rename(name, newname) / rename(source, name)

An older Microsoft KB article — KB172190, originally written for Windows NT and XP — explains how to adjust or disable the 15-second default cache window through the registry, if you want to go that route.

What This Means for You

For most users, File System Tunnelling is invisible and harmless. The occasional “this file looks old” confusion is the main casualty. If a spreadsheet or document suddenly shows a creation date from weeks ago, don’t panic — your file isn’t corrupted, and it isn’t a ghost from the past.

It matters most when you’re editing files through save-heavy applications. If you’ve ever noticed that a file you’ve been working on keeps its original date after repeated saves, tunnelling is quietly doing its job behind the scenes.

For IT admins managing a fleet, the registry tweak in KB172190 is worth knowing. Just keep in mind that tuning the cache window changes behavior for every application on that volume, not just the one causing the confusion.

And if your real worry is someone recovering deleted files after a reset, Microsoft now offers a Data Sanitization option in Cloud Rebuild for Windows 11 — that’s the layer tunnelling doesn’t cover.

How to Adjust or Disable It

If the 15-second metadata window bugs you, the path is through the registry. Per the KB172190 guidance written for Windows NT and XP, you can adjust the default cache window. Just keep in mind that tuning it changes behavior for every application on that volume, not just the one causing the confusion.

For most people, leaving it alone is the sanest choice. Windows is doing exactly what it was designed to do — and in this case, that’s a feature, not a bug.

Source: Windows Latest

Over to you: Have you ever opened a file’s Properties and been shocked by a creation date from weeks ago? Tell us what your Windows tunnelling surprise was.