微软工程师解释 Windows 为何会让新文件沿用已删除文件的日期

Windows为何会通过隧道机制让全新文件显示为旧的创建日期

假设你有一个名为 articles.txt 的文件，是你昨天创建的。你将它删除。几秒钟后，你在同一文件夹中创建了一个完全不同的文件，名为 article.txt。奇怪的是，当你打开它的属性时，Windows 却告诉你这个新文件是昨天创建的！

和 Windows 中的许多机制一样，这个功能已经存在了几十年，并不是 bug，而且它还有一个朗朗上口的名字：隧道机制。

它的正式名称是文件系统隧道，是 NTFS 和 FAT 的一项功能：如果你删除或重命名一个文件，然后很快在同一文件夹中创建另一个同名文件，新文件就会继承原文件的元数据，例如原文件的创建时间戳或短文件名/长文件名映射关系。

但 Windows 为什么要明知故犯地让一个全新文件看起来像旧文件？我们查阅了大量官方文档，找到了答案。

Windows 可以在短时间内记住已删除的文件

Microsoft 的 FileSystemInfo.CreationTime 文档写道：“NTFS 格式化的驱动器可能会在短时间内缓存文件元信息，例如文件创建时间。这个过程称为文件隧道。”

Microsoft 工程师 Raymond Chen 曾在 2005 年撰文介绍这一机制，并将其有趣地类比为量子隧穿，这也是该名称的由来。

在量子力学中，隧穿是指粒子能够出现在能量屏障的另一侧，尽管它本不应具备穿越该屏障所需的能量。

Chen 开玩笑说，Windows 的文件元数据也玩了同样的把戏：它在一侧被删除，却在另一侧重新出现。

“在文件系统隧道中，这些信息似乎违反了经典力学定律。信息已经被销毁（通过删除或重命名文件），却不知为何能够在时间屏障的另一侧重构自身。”

他还提到，Windows 95 中负责构建该功能的开发人员过于沉迷于这个类比，甚至将内部数据结构命名为夸克！

文件系统隧道如何工作？

• 当文件被删除或重命名时，Windows 会在隧道缓存中创建一条记录。
• 如果你在短时间窗口内于同一目录中创建同名新文件，Windows 就会将缓存的元数据（创建时间、SFN/LFN 映射关系）应用到新文件上。
• 该缓存按卷存储，空间不足时会自动清除较旧的记录。

在担心隐私和安全问题之前，需要注意的是，被删除的文件确实已经消失，其内容不会恢复。Windows 保留 15 秒的是元数据，其中包括创建时间，以及文件长文件名与 8.3 短文件名之间的关联。

此外，缓存也不会永久存在。它属于目录，是临时性的，只有在相应的创建或重命名操作于其时间窗口内发生时才会生效。新文件不会仅仅因为与上个月删除的文件同名，就自动继承旧的时间戳。

如果你确实担心有人在重置 Windows 后恢复已删除的文件，Microsoft 已在云重建中新增了数据清理选项。

总之，真正的问题是：文件系统隧道为什么会存在？

Microsoft 创建文件隧道并不是为了让你困惑

当我们使用 Word 之类的程序编辑昨天创建的文档并保存时，我们会希望文件保留原来的创建日期，因为我们是在编辑文件，而不是创建新文件。

然而，正如 Chen 所说：“但在内部，许多程序会通过组合执行保存、删除和重命名操作来保存文件。”

这意味着许多应用程序并不会直接修改现有文件。程序可能会创建一个包含更新内容的临时文件，删除原文件，然后将临时文件重命名为原文件名。这被称为安全保存方法。

在我们看来，这只是编辑并保存文档。但 Windows 看到的却是一个文件被创建、删除，然后重命名。

如果没有隧道机制，即使我们并没有创建新文档，替换后的文件也会突然获得一个全新的创建日期。

不过，这并不是唯一原因。Chen 举的另一个例子涉及只能识别 8.3 短文件名的旧程序。如果这类程序替换了“File with long name.txt”，却没有保留长文件名和短文件名之间的关联，文件可能会彻底失去易读的名称，最终只显示类似 DOS 时代的短文件名。

在 16 位应用程序中，只能使用短文件名（SFN）。当文件被重命名或重新创建时，隧道机制会保留 SFN 与 LFN（长文件名）之间的关联。

基本上，文件系统隧道的存在，是为了支持应用程序采用的安全保存模式，并维持 8.3 短文件名与长文件名之间的兼容性。

哪些成对操作会导致文件名“name”发生隧道传递

Microsoft 的 FltGetTunneledName 文档将这一机制描述为按卷存储的隧道缓存。

文档列出了可能触发隧道机制的操作组合。

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

如果你感兴趣，Microsoft 一篇早期、最初为 Windows NT 和 XP 撰写的 KB 文章提到，可以通过注册表调整或禁用隧道机制的15 秒默认缓存窗口。

所以，下次当一个新文件声称自己已经存在了好几天时，Windows 可能并没有出错。它也许只是在准确执行 Microsoft 设计的功能。

Windows为何会通过隧道机制让全新文件显示为旧的创建日期

假设你有一个名为 articles.txt 的文件，是你昨天创建的。你将它删除。几秒钟后，你在同一文件夹中创建了一个完全不同的文件，名为 article.txt。奇怪的是，当你打开它的属性时，Windows 却告诉你这个新文件是昨天创建的！

和 Windows 中的许多机制一样，这个功能已经存在了几十年，并不是 bug，而且它还有一个朗朗上口的名字：隧道机制。

它的正式名称是文件系统隧道，是 NTFS 和 FAT 的一项功能：如果你删除或重命名一个文件，然后很快在同一文件夹中创建另一个同名文件，新文件就会继承原文件的元数据，例如原文件的创建时间戳或短文件名/长文件名映射关系。

但 Windows 为什么要明知故犯地让一个全新文件看起来像旧文件？我们查阅了大量官方文档，找到了答案。

Windows 可以在短时间内记住已删除的文件

Microsoft 的 FileSystemInfo.CreationTime 文档写道：“NTFS 格式化的驱动器可能会在短时间内缓存文件元信息，例如文件创建时间。这个过程称为文件隧道。”

Microsoft 工程师 Raymond Chen 曾在 2005 年撰文介绍这一机制，并将其有趣地类比为量子隧穿，这也是该名称的由来。

在量子力学中，隧穿是指粒子能够出现在能量屏障的另一侧，尽管它本不应具备穿越该屏障所需的能量。

Chen 开玩笑说，Windows 的文件元数据也玩了同样的把戏：它在一侧被删除，却在另一侧重新出现。

“在文件系统隧道中，这些信息似乎违反了经典力学定律。信息已经被销毁（通过删除或重命名文件），却不知为何能够在时间屏障的另一侧重构自身。”

他还提到，Windows 95 中负责构建该功能的开发人员过于沉迷于这个类比，甚至将内部数据结构命名为夸克！

文件系统隧道如何工作？

• 当文件被删除或重命名时，Windows 会在隧道缓存中创建一条记录。
• 如果你在短时间窗口内于同一目录中创建同名新文件，Windows 就会将缓存的元数据（创建时间、SFN/LFN 映射关系）应用到新文件上。
• 该缓存按卷存储，空间不足时会自动清除较旧的记录。

在担心隐私和安全问题之前，需要注意的是，被删除的文件确实已经消失，其内容不会恢复。Windows 保留 15 秒的是元数据，其中包括创建时间，以及文件长文件名与 8.3 短文件名之间的关联。

此外，缓存也不会永久存在。它属于目录，是临时性的，只有在相应的创建或重命名操作于其时间窗口内发生时才会生效。新文件不会仅仅因为与上个月删除的文件同名，就自动继承旧的时间戳。

如果你确实担心有人在重置 Windows 后恢复已删除的文件，Microsoft 已在云重建中新增了数据清理选项。

总之，真正的问题是：文件系统隧道为什么会存在？

Microsoft 创建文件隧道并不是为了让你困惑

当我们使用 Word 之类的程序编辑昨天创建的文档并保存时，我们会希望文件保留原来的创建日期，因为我们是在编辑文件，而不是创建新文件。

然而，正如 Chen 所说：“但在内部，许多程序会通过组合执行保存、删除和重命名操作来保存文件。”

这意味着许多应用程序并不会直接修改现有文件。程序可能会创建一个包含更新内容的临时文件，删除原文件，然后将临时文件重命名为原文件名。这被称为安全保存方法。

在我们看来，这只是编辑并保存文档。但 Windows 看到的却是一个文件被创建、删除，然后重命名。

如果没有隧道机制，即使我们并没有创建新文档，替换后的文件也会突然获得一个全新的创建日期。

不过，这并不是唯一原因。Chen 举的另一个例子涉及只能识别 8.3 短文件名的旧程序。如果这类程序替换了“File with long name.txt”，却没有保留长文件名和短文件名之间的关联，文件可能会彻底失去易读的名称，最终只显示类似 DOS 时代的短文件名。

在 16 位应用程序中，只能使用短文件名（SFN）。当文件被重命名或重新创建时，隧道机制会保留 SFN 与 LFN（长文件名）之间的关联。

基本上，文件系统隧道的存在，是为了支持应用程序采用的安全保存模式，并维持 8.3 短文件名与长文件名之间的兼容性。

哪些成对操作会导致文件名“name”发生隧道传递

Microsoft 的 FltGetTunneledName 文档将这一机制描述为按卷存储的隧道缓存。

文档列出了可能触发隧道机制的操作组合。

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

如果你感兴趣，Microsoft 一篇早期、最初为 Windows NT 和 XP 撰写的 KB 文章提到，可以通过注册表调整或禁用隧道机制的15 秒默认缓存窗口。

所以，下次当一个新文件声称自己已经存在了好几天时，Windows 可能并没有出错。它也许只是在准确执行 Microsoft 设计的功能。