Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

DiskUtils.GetWindowsRealPathByHandle retries GetFinalPathNameByHandle after a hard failure and ignores the required buffer size

未关闭 适合新手
  • 哪里不对？
#252 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 5 天内回复

@hamdiakin 已经在做这个了。

开始于 2026年10月26日。

  • #255 来自 @hamdiakin —— 未关闭

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
74/100
Issue 类型
重构
描述清晰度
描述清楚
活跃度
活跃
技术栈
csharp
领域
performance

调研方向

从TruePath/DiskUtils.cs开始，具体查看DiskUtils.GetWindowsRealPathByHandle及其局部函数GetPath。检查GetFinalPathNameByHandle如何报告失败以及所需的缓冲区大小，然后根据建议更新重试行为。完成标准是：硬性失败时不重试并返回null；缓冲区过小时，使用报告的所需大小重试。

由索引模型根据 Issue 内容生成。

描述

enhancement help wanted

DiskUtils.GetWindowsRealPathByHandle calls GetFinalPathNameByHandle through the local GetPath function: first with a 256-char buffer, then, if that "fails", with a WindowsMaxPath (32,767-char) buffer:

if (GetPath(256, out var realPath) == false)
{
    if (GetPath((uint)WindowsMaxPath, out realPath) == false)
        return null;
}

GetPath returns false in two different situations, and the caller handles both the same way:

  1. result == 0: a real error. According to the GetFinalPathNameByHandle documentation, 0 means the function failed (e.g. ERROR_PATH_NOT_FOUND, ERROR_NOT_ENOUGH_MEMORY, ERROR_INVALID_PARAMETER). A larger buffer can't fix any of these, yet the code still retries with a 32,767-char buffer: one more P/Invoke and one 64 KiB char[] rent that cannot succeed.
  2. result > bufferSize: buffer too small. In this case the return value is the exact required size, including the terminating null. The code discards it and rents a 32,767-char buffer instead. For example, a path of 300 characters needs 301 chars but gets a 64 KiB array.

Neither case produces a wrong result. This is wasted work on an uncommon path. It is not a correctness failure.

Recommendations

  • Retry only when the buffer was too small (result > bufferSize), and use result as the new buffer size.
  • On result == 0, return null immediately (the caller already falls back to the original path).
  • Optionally, the first attempt could use a stackalloc'd MAX_PATH-sized buffer, so the pool is only touched for long paths.
主要语言
C#
星标
111
派生
25
平均合并
5 天 23 分钟
30 天内合并 PR
10

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

ForNeVeR/TruePath 的其他 Issue

查看 ForNeVeR/TruePath 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。