Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン 初心者向け
  • 何か問題がありますか？
#252 コメント 1 件 リアクション 0 件 担当者 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#
スター
109
フォーク
26
平均マージ
5日 23分
マージ済み PR（30日）
10

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ForNeVeR/TruePath のほかの issue

ForNeVeR/TruePath の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。