为何在Windows NTFS文件系统中可替换无法删除的文件？

最近在Windows（NTFS文件系统）上折腾Gradle项目时，碰到了一个挺有意思的怪事，跟大伙唠唠——我本地的Gradle缓存文件夹里堆着一堆项目依赖的Java .jar文件，这些Jar都是从项目配置的云存储仓库拉下来的。平时更新这些Jar我有三种路子：

• 第一种是在Gradle项目里跑完全刷新依赖的命令：./gradlew clean build --refresh-dependencies，这招会强制重新拉取所有依赖，直接把缓存里的旧Jar给替换掉。
• 第二种是手动删掉缓存里对应的子文件夹，再重新同步项目，Gradle发现依赖缺失就会自动重新下载新的Jar。
• 第三种是直接找到缓存里的目标Jar文件，手动用新版本的Jar覆盖掉旧的（比如从别的地方拷过来替换）。

本来我以为这三种方式都能达到更新Jar的效果，结果实际测试发现了离谱的情况：手动覆盖Jar之后，Gradle有时候居然还是会读旧的Jar内容，哪怕我把IDEA、Gradle进程都重启了，甚至重新同步项目都没用！

后来查了NTFS的特性才搞明白，这大概率是NTFS的文件缓存机制或者硬链接/重解析点在搞鬼：Gradle缓存里的Jar文件有时候会被系统或者Gradle本身创建硬链接，当你手动覆盖文件时，可能只是改了其中一个链接指向的文件，而Gradle实际读取的是另一个链接对应的旧文件；另外Windows的文件系统缓存会保留文件的内容快照，哪怕文件被替换了，如果进程没主动刷新文件句柄，还是会读到旧内容。

给大伙几个靠谱的解决方法：

• 如果要手动更新缓存里的Jar，别直接覆盖，先把原文件彻底删掉，再把新Jar放进去，这样能避开硬链接的坑。
• 优先用Gradle自带的--refresh-dependencies命令更新，Gradle会主动处理缓存的文件句柄和链接，确保读到的是最新的依赖。
• 实在碰到顽固的缓存问题，可以试试清空Windows的文件缓存，执行命令：rundll32.exe advapi32.dll,ProcessIdleTasks，不过这招比较粗暴，万不得已再用哈。

内容的提问来源于stack exchange，提问作者DevelopingDeveloper