Fatal编程技术网
  • winapi/
  • Winapi 我应该处理比MAX_PATH长的文件吗？

Winapi 我应该处理比MAX_PATH长的文件吗？

winapi

Winapi 我应该处理比MAX_PATH长的文件吗？,winapi,max-path,Winapi,Max Path,刚刚有个有趣的案子 我的软件报告了由于路径比MAX_path长而导致的故障 路径在我的文档中只是一个普通的旧文档，例如： C:\Documents and Settings\Bill\Some Stupid FOlder Name\A really ridiculously long file thats really very very very..........very long.pdf 总长度为269个字符（最大路径==260） 用户没有使用外置硬盘或类似的东西。这是Windows托管

刚刚有个有趣的案子

我的软件报告了由于路径比MAX_path长而导致的故障

路径在我的文档中只是一个普通的旧文档，例如：

C:\Documents and Settings\Bill\Some Stupid FOlder Name\A really ridiculously long file thats really very very very..........very long.pdf
总长度为269个字符（最大路径==260）

用户没有使用外置硬盘或类似的东西。这是Windows托管驱动器上的文件

所以我的问题是。我应该在乎吗

我不是说我可以处理长路径，我是在问我应该吗。是的，我知道一些Win32 API上存在“\？\”unicode攻击，但这种攻击似乎不是没有风险的（因为它改变了API解析路径的行为），而且并非所有API都支持这种攻击

总之，让我陈述一下我的立场/主张：

  • 首先，如果用户使用的应用程序使用了特殊的Unicode破解，那么用户能够突破这一限制的唯一方法可能就是。这是一个PDF文件，所以也许她使用的PDF工具使用了这个黑客
  • 我试图复制这个（通过使用unicode破解）并进行了实验。我发现，尽管文件出现在资源管理器中，但我对它无能为力。我无法打开它，我无法选择“属性”（Windows 7）。其他常用应用程序无法打开该文件（例如IE、Firefox、记事本）。Explorer也不允许我创建太长的文件/目录，它只是拒绝了。命令行工具cmd.exe同上
    • 因此，基本上可以这样看：一个胭脂工具允许用户创建一个很多窗口（例如资源管理器）都无法访问的文件。我可以认为我不应该处理这个问题

    （顺便说一句，这不是对短最大路径长度的赞成票：我认为260个字符是个笑话，我只是说如果Windows shell和一些API不能处理>260，那么我为什么要呢？）

    那么，这是一个公平的观点吗？我应该说“不是我的问题”吗

    更新：刚刚有另一个用户有同样的问题。这次是mp3文件。我错过什么了吗？这些用户如何创建违反MAX_路径规则的文件？

    您自己的API不应硬编码路径长度的固定限制（或任何其他硬限制）；但是，您不应该为了完成某些任务而违反系统API的先决条件。事实上，Windows限制路径名的长度是荒谬的，应该被认为是一个bug。也就是说，不，我建议您不要尝试使用除文档记录之外的各种系统API，即使这会导致某些不需要的行为，例如限制最大路径长度。总之，你的观点是完全公平的；如果操作系统不支持它，那么操作系统就不支持它。也就是说，您可能希望向用户明确这是Windows的限制，而不是您自己的代码。

    这不是一个真正的问题。NTFS支持最多32K的文件名（32767个宽字符）。您只需要使用正确的API和正确的文件名语法。基本规则是：文件名应该以
    “\\？\”
    （请参阅）开头，如
    \？\C:\Temp
    。与UNC使用的语法相同：
    \\？\UNC\Server\share\Path
    。重要的是要了解，您只能使用API函数的一小部分。例如，查看函数的MSDN描述

    CreateFile
CreateDirectory 
MoveFile
    等等

    您将看到如下文本：

    在该函数的ANSI版本中， 该名称仅限于最大路径 人物。将此限制扩展到 32767个宽字符，调用 Unicode版本的函数和 在路径前添加“\？\”。更多 有关详细信息，请参见命名文件

    此功能可以安全使用。如果您拥有来自
    CreateFile
    的文件句柄，则可以不受任何限制地使用
    hFile
    （
    ReadFile
    ，
    WriteFile
    等）使用的所有其他函数

    如果你编写一个程序，比如病毒扫描器或备份软件或者一些运行在服务器上的好软件，你应该编写程序，这样所有文件操作都支持文件名，达到“强”>“32 K < /强”字符，而不是“代码> Max Spult字符。

    < P>这是在C或C++中编写的大量软件中的一个限制。包括MSFT代码，尽管他们一直在削减它。这只是Win32限制的一部分，例如，通过Win32_FIND_数据，文件名（而不是路径）的长度仍然有一个硬上限。即使是.NET也有一个原因。这不会很快消失，Win32仍然很强大，石器时代的C字符串不会消失

    毫无疑问，在您向客户展示另一个以同样方式失败的程序之前，您的客户可能不会对此表示同情。但是，请确保您的代码能够可靠地检测到潜在的字符串缓冲区溢出，然后进行合理的诊断。不赞成程序轰炸堆损坏。

    正如您提到的，许多Windows Shell函数只在最大路径上工作。Windows XP和我相信Vista在资源管理器中嵌套长文件名的目录时都存在问题。我还没有检查Windows7——也许他们已经修复了。不幸的是，这意味着用户很难浏览这些文件

    如果您真的希望支持长路径，则需要检查Shell32.dll中使用的所有采用路径的函数，以确保它们支持长路径。对于那些不需要的，您必须使用Kernel32函数自己编写它们

    如果您决定使用Shell32并限制为MAX_PATH，那么最好编写代码以支持长文件路径。如果Microsoft以后更改Shell32（或创建替代方案），您将能够更好地添加对它们的支持

    只是为了给这个问题增加几个方面，请记住文件名是UTF-16，您可能会遇到区分大小写的非NTFS或FAT文件系统

    一种简单的方法，即使是不支持路径的软件也可以创建这些具有长路径的文件