Windows 中的回收站究竟起什么作用?它只是一个华而不实的文件夹和存放即将被删除的文件的地方,还是它有其他特定用途?
具体来说,“移动”到回收站的文件是否真的在硬盘上移动了,还是只是指向文件的指针移动了?我是一个相当有经验的用户,我只是想更深入地解释一下回收站。
答案1
引用被删除后,元数据文件将保留在回收站中以了解原始位置。
早期,在 Windows 95 和 98 中,它位于\RECYCLED
。在 Windows 2000 及更高版本中,它被重命名为\RECYCLER
。自 Windows Vista 起,它现在是一个名为 的特殊文件夹 \$Recycle.Bin
。
使用进程监控要查看底层的 I/O,请放置过滤器Recycle.Bin
并访问它。:)
例如,当我这样做时:
notepad \$RECYCLE.BIN\S-1-5-21-0192837465-987654321-0123456789-1000\$EXAMPL5
笔记:长文件夹名称是用户 SID。最后一个文件夹名称是基于元数据的哈希。
我得到一个包含如下元数据信息的文件:
Ö¸ÌC : \ P a t h \ T o \ S o m e \ E x a m p l e . t x t
文件路径中间有空格的原因是它存储在宽字节字符中,以支持某些语言的特殊字符以及 unicode 和其他字符。早期的符号是二进制的,包含文件大小和权限等信息,以及指向文件数据的指针。本质上,它包含足够的信息来重建原始引用...
遗憾的是《Windows Internals》这本书没有涉及这一点,否则我会有更多的参考资料。我还没有找到任何详细介绍这一点的文章,无论是微软还是第三方人士。它们可能确实存在,但我发现对主要概念进行逆向工程更容易......
答案2
我对此进行了广泛的研究,但令人惊讶的是,网上关于回收站实际如何实现的信息却很少。
一切都没有那么难掌握。当你删除垃圾箱中的文件时,它实际上并没有被移动到垃圾箱中。
首先,让我们看一下子文件夹$Recycle.Bin
:
C:\$Recycle.Bin\S-1-5-18
是内置系统帐户的文件夹C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1XXX\
,从 1000 开始都是非内置用户文件夹。您应该首先通过whoami /all
在命令提示符中输入来获取您的 SID 或wmic useraccount get name,sid
获取所有本地帐户 SID 来检查哪一个是您需要的,然后选择与 SID 匹配的文件夹。
如果您将所有这些文件夹的安全权限授予您的帐户,Explorer 可能会在每个文件夹中显示您已删除的文件,但这只是 Explorer 错误。如果您导航到C:\$Recycle.Bin\S-1-5-18
文件夹并键入dir /a
,您将看到它实际上是空的,并且只有与您的 SID 匹配的文件夹才包含您已删除的文件。
请注意,即使您是 PC 上的唯一用户,您仍可能有一个C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1000\
很可能是空的文件夹。那么您的实际文件夹将是...-1001\
。用户“1000”似乎是 Windows 在安装或某些更新时自动创建的用户的悬空文件夹,然后被删除。但Recycle.Bin
文件夹没有被销毁,只是留在那里。我认为删除这个悬空文件夹是安全的。我不太确定C:\$Recycle.Bin\S-1-5-18
,但我相当确定它也是安全的,因为无论如何,OS SYSTEM 帐户都不需要使用 Bin。
因此,删除算法如下:
- 系统创建硬链接已删除文件位于
C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1XXX\
名为的文件夹中$RXXXXXX.<file_ext>
,其中XXXXXX
是根据文件内容计算出的 6 个符号 HASH,正如我所假设的。 - 元数据文件在同一个文件夹中创建,名称为
$IXXXXXX.<file_ext>
。稍后我将向您展示此文件的内容。 - 原始文件被删除,但由于 中的额外硬链接
$Recycle.Bin
,实际文件的数据仍保留在驱动器上的同一位置,就像文件从未被触碰过一样。它没有被移动到任何地方。这就是为什么每个逻辑卷必须有自己的$Recycle.Bin
文件夹,因为硬链接只能在同一卷内工作。
就是这样。恢复算法:
- 读取元数据文件并
$RXXXXXX.<file_ext>
根据$IXXXXXX.<file_ext>
原始文件位置中的信息和原始文件名创建硬链接。 - 元数据和备份文件均从中删除
$Recycle.Bin
很简单,不是吗?
现在,最有趣的部分是元数据文件:
0000 02 00 00 00 00 00 00 00 <-- File header (QW)
0008 00 7C 0A 00 00 00 00 00 <-- File size (QW)
0010 90 83 72 44 28 9C D8 01 <-- File deletion date (QW)
0018 18 00 00 00|43 00 3A 00 <-- File path string length (DW)
0020 5C 00 24 00 52 00 65 00
0028 63 00 79 00 63 00 6C 00
0030 65 00 2E 00 42 00 69 00
0038 6E 00 5C 00 66 00 73 00
0040 73 00 2E 00 65 00 78 00
0048 65 00 00 00| <-- |Null-terminated path string| (wchar_t)
所有值小端序格式。
标头是固定的,并且对于所有文件都是相同的。请注意,某些$I
文件可能在标头之前出现一些垃圾字节FF FE
。我不知道这是做什么用的,所以在继续阅读之前,您应该检查完整的标头。
删除日期为文件时间格式,并可以转换为通常系统时间通过文件时间至系统时间。它代表自 1601 年 1 月 1 日(UTC)以来的 100 纳秒间隔。
所以它不是超级复杂的文件格式,但设计相当有趣。
我计划自己使用这些信息,为 Windows 创建自定义“垃圾收集器”,将其添加到任务计划程序中,定期启动并扫描\删除 24 小时前删除的文件等。我知道 Windows 10 有内置选项,但它不灵活也不可靠(它有时会留下元数据文件,而只删除$R
文件)。此外,我认为以前的 Windows 版本根本没有此功能。
我鼓励您也尝试一下!例如,您的程序可能会将其删除的所有文件的元数据信息保存到某个数据库中,这样您就可以拥有所有删除过的文件的完整历史记录!