我在看FlyTech 的视频,当他制作了一对非法文件夹(一个名为“<”,另一个名为“>”)时,它让 Windows 认为包含它们的文件夹已损坏。对于具有非法字符的任何其他文件夹,似乎都不会出现此行为。
我想知道为什么这种特定的组合会让 Windows 认为包含的文件夹已损坏。我搜索了一下,找不到为什么会这样。谁能解释一下?
我在看FlyTech 的视频,当他制作了一对非法文件夹(一个名为“<”,另一个名为“>”)时,它让 Windows 认为包含它们的文件夹已损坏。对于具有非法字符的任何其他文件夹,似乎都不会出现此行为。
我想知道为什么这种特定的组合会让 Windows 认为包含的文件夹已损坏。我搜索了一下,找不到为什么会这样。谁能解释一下?
该错误不是完全由尖括号引起的,也不是由两个尖括号引起的 - 相反,它发生在 1) 文件名在其名称中包含通配符,以及 2) 通配符与以前看到的文件匹配,这会导致 Windows认为文件夹搜索不会像应有的那样向前推进。
首先,据我了解,在 Windows 上列出目录是通过通配符扩展完成的(与在 Linux 上完成的方式相反)。要扩展通配符模式,首先使用初始模式调用 FindFirstFile(),然后在 NTFS 逐个查找匹配文件时重复 FindNextFile()。要列出整个目录,您可以执行与
*
模式相同的操作。其次,在 Windows 文件处理代码的更深层部分,
<
和>
(以及"
)实际上都被视为通配符——它们的行为类似于历史上的MS-DOS 通配符变体*
和?
。(例如,>
又名 DOS_STAR 匹配文件扩展名之前的所有字符。)公开可用的.NET 源代码包含对该算法的描述,该描述与在泄露的 Windows NT 内核源中找到的相同。因此,它不仅是尖括号,而且还
"
?
*
可以用来触发这个错误——只要它们与另一个在通配符之前排序的文件名结合使用,如果排序是通过 Unicode 值完成的(其中是 NTFS 强制执行的命令)。例如,如果您有名为
foo(
and的项目,您也会收到“文件夹损坏”错误foo*
。这里没有什么特别之处(
,除了它*
在 Unicode 中出现在前面——而在后面排序的字符*
不会foo+
触发错误。(如果您想查看这些字符的 Unicode 位置,可以通过charmap.exe 打开“字符映射”。)同样,包含 [
foo<
,foo=
] 或 [foo?
,fooo
] 的目录不会触发这种情况,但包含 [foo=
,foo>
] 或 [foo+
,foo?
] 的目录会。因此,如果我正确理解所有内容,似乎会发生以下情况:
foo(
,foo*
],NTFS 强制执行此确切顺序。*
”开始。foo(
.foo(
”。foo(
(完全匹配)并返回下一项foo*
。foo*
”。foo*
- 它被识别为通配符并foo(
首先匹配,因此下一项foo*
再次出现 - 因此引发错误。与通配符
>
的处理方式类似*
,名为“>
”的文件夹通过匹配其<
自身之前的前一个“ ”项会导致相同的问题。字符属于“保留字符”组
<
,>
在 Windows 中不得用于命名文件或目录。https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
如另一个答案所述,这些字符位于保留字符组中:
https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
每一个都有非常具体的原因。有很多方法可以绕过它们,但每种方法在命令处理中都有一个基本功能: