外部 HDD 上的某些文件夹和/或文件可在 Linux 上访问，但不能在 macOS 和 Windows 上访问

我发布这个答案只是为了说明问题是如何解决的，从而总结了对原始问题的评论，这可能对其他人有用。

我已经解决了在 Linux 中创建这些文件夹的问题，只需缩短两个或三个视频文件的标题，这些文件的名称很长，但没有明显奇怪的字符，如逗号、括号等。我也更改了文件夹名字——尽管它们并没有什么特别之处。将它们改回来并没有重现问题。

因此，文件夹名称有一些错误字符在 Linux 上不可见，或者三个重命名文件中的一些错误字符使整个文件夹在 Mac 中不可见，并且其所有包含在 Windows 中都无法播放。

这是最奇怪的事情，在重命名文件夹和三个文件之前，没有一个文件可以在 Windows 中播放。

正如@Giacomo1968 在评论中所说：

'......原始文件名中的“幻影”字符......类似于回车或不间断空格，在 Linux 中以一种方式处理，但在其他系统中被阻塞。

问题是，在解决问题之前，我尝试在 Windows 中播放其他文件，而不是最终重命名的文件。幻影字符也可能在文件夹名称中。

它再次发生在一个格式化为 exFAT 的新驱动器上，并且文件夹中的其他文件在复制过程中 Nemo 文件管理器在 Linux 中报告了错误（类似于“无法创建文件”），但实际上一切看起来都很好Linux。该文件夹已被看到，但在 Windows 中仍然完全无法访问（我不完全记得错误消息，关于文件或文件夹不存在的内容），并且在 Mac 上可以看到，除了一个文件，它仍然不可见。在Linux中重命名文件夹和同名文件后一切正常！

我现在怀疑问题中报告的初始问题的原因以及错误“幻像”字符的创建是复制过程中的一些错误或粘贴从互联网页面复制的文本标题（看起来像例如，空间实际上是别的东西）。这是因为在 Linux 中使用 Double Commander 进行复制时，它报告了一些名称的详细错误，其中包括可能是制表符或类似字符的空格。

（为了避免从互联网上复制/粘贴所选文本时出现此类错误，类似Firefox 的“仅复制文本”插件可能非常有用。）

最后，复制的最佳解决方案是在Linux中使用Double Commander，它非常清楚地指出了有问题的文件名。

命名文件或文件夹时必须谨慎复制/粘贴 Internet 文本。

微软网站上讨论了文件/文件夹名称在 Windows 上的工作方式。然而，这仅提供了整体真相的一瞥。

注意：我不会讨论可能由“外部”系统访问 NTFS 卷的方式引起的代码页问题。我认为评论和其他答案已经充分涵盖了这一点。我将主要限制在以下两个方面：

• 路径名长度限制
• 从 Win32 子系统难以/不可能访问的字符组合

至于文件系统，我将自己限制为 NTFS，就像问题一样。考虑来自上述链接网站的以下评论：

不要以空格或句点结尾的文件或目录名称。尽管底层文件系统可能支持此类名称，但 Windows shell 和用户界面不支持。

现在，我们需要先弄清楚一些术语。我们处理各种......层，可能是一个合适的术语：

• 文件系统，例如 NTFS
• NT 对象管理器和其他内核工具，但主要是对象管理器的名称
  （如果您想查看它，请使用WinObj 之类的工具）
• Win32 子系统（这就是上面所说的“Windows shell 和用户界面”）
• 另一个“元方面”是操作系统版本，因为支持的路径长度可能会有所不同

一个很好的解决方法是在客户端伪装成 NTFS 的 Samba 共享。但 Windows NTFS 卷也可以。我们将在 Windows 上从命令行“玩转”（点击Win+R并键入cmd，然后点击Enter）。

本地 NTFS 卷

假设我们想要创建一个无效的文件名（注意尾随的点？！）：

echo NONSENSE > text.txt.

尝试这样做时，结果确实是test.txt，而不是 test.txt.。Win32 子系统 (csrss.exe) 阻止我们做愚蠢的事情。嗯，有意思吧？

考虑另一个声明：

不要使用以下保留名称作为文件名：

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, 和LPT9. 还要避免这些名称后跟扩展名；例如，NUL.txt不推荐。

嗯，NUL听起来很有趣。我们知道这是/dev/null从 DOS 时代继承而来的 unixoid 系统的替代品。

echo NONSENSE > NUL

啊对。它是 的替代品/dev/null，因此输出将被吞噬。但不要使用如此诱人的声音。因此，让我们使用零项目博客文章“本地设备”部分中总结的信息。

小插曲：%CD%

如果您对经典的 Windows 命令行 ( ) 不太熟悉cmd.exe，特殊变量%CD%将为我们提供当前工作目录的绝对路径。在下一节中请记住这一点。因此，如果您当前在里面C:\test，该命令echo %CD%将产生输出C:\test。这是进行实验的便捷捷径。

正如我们可以从零项目一文中了解到的，有许多方法可以在 Win32 子系统级别避开路径名称转换。一种这样的方法是在\\?\内部直接转换为 的前缀\??\，在较新的 Windows 版本上与\GLOBAL??\. 这称为对象目录（请不要将其与文件系统实体混淆，尽管术语相似！）。同样，WinObj 和类似的工具可以让您调查对象管理器名称空间。

插曲：命名空间和终端服务器“东西”

任何看过 Windows NT 历史并且 Windows 10 可以追溯到 NT 的人都会记得你必须单独许可终端服务的时间。即能够与不同用户远程连接到一台机器。

我认为是 Windows XP 通过允许同时使用多个用户帐户保持登录（“用户切换”）为大众带来了这一点，并且可能 Windows 2000 或 2003 Server 将其包含在标准版中，即使 CAL需要超出默认包含的最低“席位”。

这就是区别\??和\GLOBAL??起源的地方。\GLOBAL??是所有登录会话共享的“DOS”设备名称的视图。

\??现在可以在名为 的符号链接（同样，不是文件系统实体！）中看到\DosDevices，它提供了有关其来源的线索。这是“DOS”设备名称（例如C:网络驱动器映射）所在的位置。C:反过来，在现代系统上将是一个符号链接\Device\HarddiskVolume1（或类似链接）。这通常是由存储驱动程序堆栈中的某个驱动程序创建的实际设备对象，在这种情况下，它应该是 NTFS 文件系统驱动程序。

所以当你双击C:\Windows\explorer.exe内部发生的事情是路径被转换：

• 在 Win32 子系统级别，通常的更改是添加\??\.
• 然后对象管理器将展开\??\C:.
  • 首先\??\在您的登录会话的“DOS”设备名称空间中结束（请参阅下面的备注）
  • 最终，对象管理器计算出类似于\??\C:等价于的东西\GLOBAL??\C:——正如我们在上面看到的——等价于\Device\HarddiskVolume1.

然后，对象管理器会将路径的其余部分传递\Windows\explorer.exe给负责设备对象\Device\HarddiskVolume1的驱动程序，确保驱动程序知道引用了哪个设备对象。并且该驱动程序将知道如何在自己的命名空间内处理路径的特定剩余部分。

备注：当您在内部引用时，\??您最终会看到本地登录会话的“DOS”设备。这可以用映射的网络驱动器来解释。假设您有一个X:为远程共享映射的驱动器号。假设您使用“用户切换”，或者这是在一个强大的终端服务器上运行，另外 200 个用户同时登录。在这种情况下，我们手头有两个问题。虽然系统驱动器（例如物理磁盘）可能由每个人共享，但销售人员可能已映射“销售份额”，X:而开发人员可能已映射“开发份额”。这同样适用于通过分配的“驱动器号”subst. 这应该可以解释为什么“DOS”设备名称不能有一个适合所有人的全局命名空间。

所以我们的目标是创建一个名为的文件（或目录）NUL，而 Win32 子系统不允许我们这样做。它只是吞下了输出，并且从未在我们的工作目录中创建该文件。然而，利用上述链接文章和前一段插曲中的信息，我们可以通过在子系统级别回避那些讨厌的路径转换来解决这个问题，方法是发出：

echo NONSENSE > \\?\%CD%\NUL

提醒一下，%CD%扩展为当前工作目录的绝对路径，假设是C:\test，上面的命令相当于echo NONSENSE > \\?\C:\test\NUL.

你瞧，快速dir证明文件已创建。如果我们尝试使用其他“保留”名称，它也可以正常工作。

请注意，您也可以使用实际的原生 NT 路径形式（\??而不是\\?）来获得相同的效果：

echo NONSENSE > \??\%CD%\NUL

整洁的。

那么我们如何重新审视尾随点的尝试，但在没有 Win32 子系统干扰的情况下给出完整路径？：

echo ILLEGAL TRAILING DOT > \??\%CD%\test.txt.

瞧，它有效，快速dir /b证明：

C:\test>dir /b
CON
NUL
test.txt
test.txt.

插曲：UNC（通用命名约定）路径

该主题在零项目文章中进行了更详细的处理，但只要说有一种特殊形式的路径看起来与我们刚刚在上面使用的非常相似就足够了：\\.\C:\Windows\explorer.exe将是一个示例。

请记住，每当您卡在登录屏幕上时，不记得机器的本地机器名称，并且它默认为它所属的域？一种不使用实际名称来引用当前机器的.\username简单方法是，允许引用当前机器username上的用户。

.in应类似\\.\C:\Windows\explorer.exe理解。实际上，您所说的是在驱动器访问路径\\. 上的当前机器 上......并且操作系统的不同设施相互联系以实现它。\C: C:\Windows\explorer.exe

注意：UNC 路径遵循一组不同的规则，这就是为什么我只提到它们。如果您对更多详细信息感兴趣，请阅读链接的文章和 Microsoft 文档的链接。

现在我们终于创建了一个“不可能”的文件test.txt.，让我们看看它，好吗？

C:\test>type test.txt
NONSENSE

有没有搞错？我清楚地记得曾回响ILLEGAL TRAILING DOT到该文件中。

啊，当然。就像我们最初尝试创建test.txt.Win32 子系统时再次干预并“有帮助地”将我们的名称转换为test.txt. 所以我们实际上是在看\??\%CD%\test.txt而不是\??\%CD%\test.txt..

所以这应该这样做：

C:\test>type \??\%CD%\test.txt.
ILLEGAL TRAILING DOT

好多了。问题在于，并非所有程序都能像cmd.exe. 假设我们要打开记事本：

C:\test>notepad \??\%CD%\test.txt.

Dang，我们会看到以下消息框：

因此，虽然有一些方法可以规避Win32 子系统施加的一些限制，但这些方法的效用是有限且值得怀疑的。

注意：也在 Windows 上/为 Windows开发软件的读者可能还记得，使用\\?\允许回避MAX_PATH限制的前缀（过去是 260，基本上是 255 plus\\?\和终止\0）。现在您知道为什么这允许我们使用大约32767 个字符了。由于 UCS-2 被 UTF-16 取代（我认为在 XP 中），对象管理器级别的路径修改只是一个问题。另一个是，在 UTF-16 中，一旦您将BMP抛在后面，代码点可能会占用超过 16 位（又名wchar_t或） 。WCHAR

无论如何，命令行 ( cmd.exe) 为您提供了访问和删除最初能够从 Windows 创建的文件的所有工具。

Linux/Samba 共享，伪装成 NTFS

现在让我们从本地驱动器出发，考虑一个映射的网络驱动器Z:，它由 Samba 4.x 提供，就 Windows 而言，它模仿了 NTFS 驱动器。

这个实验提供了更多的见解，因为我们可以根据 Linux 端的规则创建文件，而不必担心无法从 Windows 端访问它们。

• 映射的驱动器是Z:，我们将在Z:\testWindows 端
• 在 Linux 端，卷被格式化为btrfs
  维基百科文章告诉我们，除了/and \0（又名ASCII NUL 字符）之外的所有字符都是允许的！所以这应该很有趣。

以下是一些在 Windows 端应该（或至少可能）难以访问的奢侈文件名，在 Linux 端使用 Ubuntu 20.04 上的 Bash 来创建它们：

• :.txt（创建与echo "$RANDOM" > \:.txt）
• ???.txt（创建与echo "$RANDOM" > \?\?\?.txt）
• ?.txt（创建与echo "$RANDOM" > ?.txt）
• *.txt（创建与echo "$RANDOM" > \*.txt）
• \.txt（创建与echo "$RANDOM" > \\.txt）
• ".txt（创建与echo "$RANDOM" > \".txt）
• >.txt（创建与echo "$RANDOM" > \>.txt）
• <.txt（创建与echo "$RANDOM" > \<.txt）
• |.txt（创建与echo "$RANDOM" > \|.txt）

这应该几乎涵盖了所有基础，实际上在第二次考虑表情符号甚至可能根本不是问题。NTFS 上也禁止使用正斜杠，但对于 btrfs/ POSIX/SUS也是如此。

Linux方面的证明：

$ find -type f -printf '%P\n'
:.txt
???.txt
?.txt
*.txt
\.txt
".txt
>.txt
<.txt
|.txt

现在让我们看看在 Windows 端是否可以访问以及可以访问什么...

Z:\test>dir /b
_2X68P~X.TXT
_2X68Q~5.TXT
_2X68Q~9.TXT
_2X68Q~B.TXT
_2X68Q~D.TXT
_2X68R~7.TXT
_2X68S~3.TXT
_67V3K~2.TXT
?.txt

截图为证：

哦哦哦！没错，Windows 的 DOS 遗产再次来袭。NTFS -除非主动禁用它- 能够创建所谓的 8.3 短文件名，符合 DOS 文件名要求。

And that's how we are able to access the invalid file names regardless.

Conclusion

Now recall, the question was about an external, i.e. local, NTFS drive. This means the rules we just observed for Samba shares may not apply here.

Depending on the driver used to store these files (which could vary by Linux/macOS version, e.g. ntfs-3g or the third-party driver used, e.g. Paragon's driver) I see the following possible causes left after looking at the above experiments:

1. the file name contained a :, " or ? ... this seems the most likely to me, given I'd had accidentally copied and pasted ebook titles myself, containing these characters. We can pretty much rule out / and the other "forbidden" characters are at least less likely.
2. the Windows and macOS side see the invalid name, attempt to look at the DOS 8.3 name, but none was generated. This somewhat depends on the exact Windows version and its configuration and since I have no macOS devices around, I cannot test that scenario either. Also, I am not sure whether on a Windows system where 8.3 names are enabled Windows would retroactively go and generate a 8.3 name if, say, the Linux side skipped that part. Because if I recall correctly the NTFS driver decides whether the respective record ("attribute") gets populated.
3. 超过了路径名的长度。我认为超过路径段的长度是不可能的，因为 NTFS 不允许您为路径段存储超过 255 个 16 位值，但总路径长度也可能已超过（请参阅此链接）。

对于第一种情况，我建议在 Linux 端使用fslint来清理文件（和文件夹）名称。存在其他类似的工具和 YMMV，请选择。

希望这可以帮助。花了足够长的时间将我的想法倾注到写作中。

进一步阅读

• 命名文件、路径和命名空间
• Win32 到 NT 路径转换权威指南