Windowsのショートカットは、移動したファイルをどうやって見つけるのか？ ── ファイルの「場所」と「同じファイルであること」は別の話

「下書き」フォルダーの企画書にショートカットを作り、企画書本体を「提出用」へ移しました。ショートカットを作り直していないのに、移動後の企画書を開けることがあります。元の場所にないファイルを、Windowsはどうやって見つけるのでしょうか。

これは.lnkショートカットが、保存したパスのほかに、リンク先を探し直すための情報も持てるためです。通常のリンク解決では保存した場所を確かめ、そこになければ利用できる分散リンク追跡を試し、それでも見つからなければファイルの特徴で候補を探します。追跡や探索を行うかどうかは、設定やAPIのフラグにも左右されます。Shell Links

ただし、この仕組みは見失ったリンク先を探し直すためのもので、元のファイルと同じであることを確かめる仕組みではありません。開けただけでは以前と同じファイルだとは証明できません。同じ内容のコピーは別のファイルで、元の場所に同じ名前の別ファイルを置けば、そちらを開くこともあります。

対象はWindowsのシェルが扱う、普通のファイルを指す.lnkショートカットです。説明と確認の手順はローカルの同じNTFSボリューム内でファイル本体を移動・改名する場合を中心にします。URLへのリンクやファイルシステムのシンボリックリンクは扱いません。分散リンク追跡とファイルの特徴による探索は別の仕組みです。結果は残っている情報、ファイルシステム、サービス、管理ポリシー、APIの呼び出し方などに左右されます。USB、同期フォルダー、ネットワーク共有、別のPCへの移動まで、同じ結果を保証するものではありません。分散リンク追跡の適用条件とResolveの動作条件を参照してください。

既存の実測はWindows Server 2025 Datacenter（10.0.26100、ビルド26100）の一環境で、ローカルの同一NTFSボリュームと、追跡サービスがRunningの条件に限られます。COM APIのIShellLinkW::Resolveを使った観測で、Windows 11のエクスプローラー画面での試験ではありません。結果は「既存のAPI検証結果」に、読者向けの手順とは分けて載せています。

自分のPCで挙動を確かめるなら「自分の環境で確かめる」へ、アプリからリンク先を解決するなら「アプリからの解決」へ進めます。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全5件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

ショートカットが保存している情報

.lnkはWindowsのシェルが別の対象へアクセスするための情報を保存したファイルです。プロパティの「リンク先」に表示される一行が、その情報のすべてではありません。Shell Links

flowchart TB
    accTitle: ショートカットに見える情報と保存されている情報
    accDescr: プロパティのリンク先の欄に見えるのはパスの一行で、ショートカットはそのほかにもリンク先を探すための情報を保存できます。
    P["リンク先の欄：パス1行"] -->|"ほかにも保存"| M["リンク先を探すための情報"]

図1: 「リンク先」の欄に見える一行のほかにも、リンク先を探すための情報を保存できます。

形式の仕様には場所に関する情報のほか、リンク先の属性や追跡用の追加情報を保存する欄が定義されています。各欄がすべてのショートカットで有効に使えるわけではありません。保存されている情報と、実際の探索で何を使ったかも別の話です。

• 保存した場所: 表示されるパスだけでなく、シェルの識別子リストなども関わります。通常の解決ではまずこの情報でリンク先の所在を確かめます。Shell Links
• ShellLinkHeader: リンク先の属性、作成時刻、ファイルサイズなどを記録する欄があります。ShellLinkHeader
• TrackerDataBlock: リンク先を探すときに、分散リンク追跡サービスへ渡す情報を保持する追加データです。存在するだけで追跡の成功が保証されるわけではありません。TrackerDataBlock

移動したファイルを探す順序

ショートカットの保存情報を使い、必要に応じてリンク先を探し直す処理を、リンクの解決と呼びます。アプリから明示的に行うときはIShellLinkW::Resolveを使います。保存されているパスを読み出すだけの処理は、リンクの解決とは別のものです。Shell LinksのLink Resolution

通常のリンク解決は保存された場所、追跡用の識別情報、ファイルの特徴という三つの手がかりを順に使います。個々の呼び出しでどの経路を通ったかを、この説明だけから断定することはできません。

flowchart TB
    accTitle: 保存された場所から追跡情報と特徴へ手がかりを変える
    accDescr: 保存された場所で見つからなければ利用できる追跡情報を試し、それでも見つからない場合は特徴による探索を試みます。
    P["保存した場所を確認"] -->|"見つからない"| I["追跡情報を利用"]
    I -->|"使えない・見つからない"| S["特徴が合う候補を探す"]

図2: 通常のリンク解決の大筋です。追跡や探索を行うかどうかは、設定や呼び出し方にも左右されます。

保存された場所の確認

企画書をC:\Work\下書き\企画書.txtから、同じNTFSボリューム内のC:\Work\提出用\企画書.txtへ移したとします。ファイルは一つのままですが、ショートカットが保存していたパスは「下書き」を指しています。

flowchart TB
    accTitle: 企画書の移動で古いパスと現在地が分かれる
    accDescr: ショートカットが覚えている下書きフォルダーには企画書がなく、同じ企画書は提出用フォルダーへ移っています。
    L["ショートカット：下書きを指す"] --> O["下書き：もうない"]
    O -.->|"同じ企画書"| N["提出用：ここにある"]

図3: 古い場所だけをたどる仕組みなら、ここで行き止まりになります。

Windowsのシェルが最初に確かめるのは、保存された場所に対象があるかどうかです。そこで見つかれば解決でき、見つからなければ利用できる情報で探し直します。移動後も開ける理由を考えるには、古いパスを読むだけの処理と、この探し直す処理を区別する必要があります。Shell LinksのLink Resolution

Object IDによる追跡

提出用へ移した企画書を提案書.txtへ改名すると、場所と名前の両方が変わります。それでも、元のファイルを移動・改名したのであって、別のファイルを作ったわけではありません。

分散リンク追跡は移動したリンク先を探すWindowsの仕組みで、NTFS上のファイルやフォルダーに付くObject IDなどの追跡情報を利用します。名前や作成日時などから候補を探す方法とは異なり、利用できる情報やサービスの条件に左右されます。Object IDはボリューム内のファイルやフォルダーを識別する任意の属性で、必須ではありません。そのボリュームにはObject IDの索引もあります。利用できる追跡情報があれば、古い名前を全フォルダーから探すだけでなく識別情報を手がかりにできます。Distributed Link Tracking and Object Identifiers

図4ではこの識別情報を「名札K」にたとえています。Kは説明用の記号で、実際のIDの形式ではありません。

flowchart TB
    accTitle: 同じボリュームで移動と改名をしても追える識別情報
    accDescr: 追跡情報が保たれる場合、下書きの企画書から提出用の提案書へ名前と場所が変わっても、同じ名札を手がかりに追跡できます。
    A["企画書：名札K"] -->|"移動・改名"| B["提案書：名札K"]
    B -.->|"追跡情報のKと照合"| C["Kを手がかりに追跡できる"]

図4: 「どこにあるか」が変わっても、追跡に使える識別情報まで変わるとは限りません。

.lnkのTrackerDataBlockはこの追跡サービスへ渡す情報を保存できます。ただし、すべてのショートカットがこの方法で解決されるわけではありません。TrackerDataBlock

ファイルの特徴による探索

追跡サービスを利用できない場合や、追跡で見つからない場合、シェルはファイルの特徴による探索も試みます。公式の説明では元のフォルダーやその近辺などから、名前・作成日時・属性などが合う候補を探します。IShellLinkW::ResolveのRemarks

「名札が一致した」と「特徴が似ている」では、根拠の強さが違います。同じ名前や作成日時のファイルが複数あれば、特徴だけで元の相手だとは証明できません。この探索は見失ったリンク先を探し直す処理です。内容をすべて比べて同一性を証明することはしません。

flowchart TB
    accTitle: 特徴による探索で見つかるのは候補
    accDescr: 名前や作成日時や属性で探して見つかるのは特徴が合う候補であり、特徴の一致は同じファイルであることの証明になりません。
    S["名前・作成日時・属性で探す"] --> C["特徴が合う候補が見つかる"]
    C --> N["同じファイルの証明ではない"]

図5: 特徴の一致は手がかりで、元のファイルそのものだという証明にはなりません。

場所と同一性の違い

この記事では「同じパスにある」「同じ内容を持つ」「移動前から続く同じファイルである」を区別します。パスはファイルやフォルダーの場所と名前を表す情報です。保存されたパスに対象が見つかることと、その対象が移動前から続く元のファイルであることは、別の条件です。同じNTFSボリューム内で元のファイルを移動・改名することと、内容をコピーして別のファイルを作ることも、同じ操作ではありません。Object Identifiers

リンク解決の役割はファイルの置き場所や名前が変わったときに、ショートカットからのアクセスを回復することです。利用者が必ずショートカットを作り直さなくても済むように、保存した場所以外の手がかりも使います。リンク先を見つけることと、業務で必要なファイルの同一性を確かめることは、分けて考えます。Shell Links

flowchart TB
    accTitle: ショートカットで開いたあとに確かめること
    accDescr: ショートカットで開けても、開いた対象のパスと内容を確かめてから、目的のファイルとして扱います。
    O["ショートカットで開けた"] --> P["開いたパスを確かめる"]
    P --> C["内容を確かめる"]

図6: 重要な書類は開いた対象のパスと内容を確かめてから扱います。

同じ内容のコピー

提出用の提案書.txtを「配布用」へコピーすると、同じ内容を持つファイルが二つになります。一方だけを編集しても、もう一方の内容はそのままです。「中身が同じ」と「元のファイルそのもの」は区別しなければなりません。

通常のコピーでは元と同じObject IDをそのまま引き継ぎません。同じボリュームに同じIDを持つ別ファイルが二つできると、識別子の一意性が失われるためです。Object Identifiers

flowchart TB
    accTitle: ファイルの移動とコピーで同一性の意味が違う
    accDescr: 同じファイルを移動する操作に対し、通常のコピーでは内容を持つ別ファイルが作られ、元の追跡用Object IDはそのまま複製されません。
    O["元の提案書：名札K"] -->|"通常のコピー"| C["別ファイルの提案書"]
    C --> B["名札Kは引き継がない"]

図7: 中身を同じにすることと、元のファイルそのものを移すことは違います。

元の場所に置いた別ファイル

企画書を提出用へ移したあと、空いた下書き\企画書.txtに同じ名前の別ファイルを置いたとします。通常は保存された場所の確認が先なので、そこに対象が見つかれば、移動先を探す段階へ進まないことがあります。Shell LinksのLink Resolution

flowchart TB
    accTitle: 元の場所に別ファイルがあると先に見つかる
    accDescr: 保存された場所の確認が先なので、元の場所に同じ名前の別ファイルがあればそれが見つかり、移動先を探さないことがあります。
    S["保存した場所を確認"] --> F["同じ名前の別ファイルがある"]
    F --> X["移動先を探さないことがある"]

図8: 保存した場所を先に確かめるので、元の場所に置いた別ファイルが見つかることがあります。

そのため、追跡機能があることを、移動した元のファイルを必ず選ぶ保証としては使えません。重要な書類を扱うときは「開けたから正しい」と判断せず、開いた対象のパスと内容を確認します。

Object IDとファイルID

ファイルを識別する情報には、追跡用のObject IDのほかに、ファイルハンドルから取得するファイルIDもあります。例えば二つのパスが同じ対象を指すかを比べるときは、GetFileInformationByHandleで得たファイルインデックスをボリュームの識別情報と組み合わせて使います。GetFileInformationByHandle

二つは別の項目なので、「ID」という呼び方だけで混同しないでください。ファイルIDによる比較にはボリュームの識別情報も関わり、識別子の有効範囲や再利用にも注意が必要です。どのAPIのどの識別子を、どの条件で比べるのかを確認します。GetFileInformationByHandleのRemarks

flowchart TB
    accTitle: 追跡用Object IDとファイルIDの違い
    accDescr: 追跡用Object IDは分散リンク追跡が使う任意の属性で、ファイルIDはファイルハンドルから取得し、ボリュームの識別情報と組み合わせて比べる別の項目です。
    O["Object ID：追跡が使う"] -.-|"別の項目"| F["ファイルID：比較に使う"]

図9: どちらも「ID」と呼ばれますが、取得する方法も使う場面も別です。

自分の環境で確かめる

以下は自分の環境で挙動を確認するための手順です。この改稿で新たに実行した試験の結果ではありません。開発者向けのAPIの呼び出しはエクスプローラーでの観察と分けて、「アプリからの解決」に載せています。

移動・改名後のリンク先を確認する

書き込み権限のあるローカルNTFSボリュームに、新しい検証専用フォルダーを用意します。例としてC:\ShortcutLabを使いますが、書き込めない場合は別の場所を選びます。同期フォルダーとネットワーク共有は使わず、業務ファイルや既存の同名フォルダーを上書きしないでください。サービスやポリシーの変更、Object IDの編集は不要です。

flowchart TB
    accTitle: 移動と改名を試す手順の流れ
    accDescr: ショートカットを作って一度開き、ファイル本体だけを移動して開き、さらに改名して開いて、それぞれ開いた対象を記録します。
    A["ショートカットを作り開く"] --> B["本体だけを移動する"]
    B --> C["開いて対象を記録"]
    C --> D["本体を改名する"]
    D --> E["開いて対象を記録"]

図10: ショートカット自体は動かさず、本体を移動・改名するたびに開いた対象を記録します。

1. 検証専用フォルダーの中に「下書き」と「提出用」を作成します。

   二つのフォルダーを同じNTFSボリューム内に置きます。使用したOS、ビルド、保存場所も記録します。

2. 「下書き」に企画書.txtを作り、「移動する元ファイル」など判別用の文字を保存して閉じます。

3. そのファイルへのショートカットを作り、検証専用フォルダーに置いて、一度開きます。

   元のファイルが開き、判別用の文字が見えることを確認して閉じます。以降、ショートカット自体は移動せず、リンク先を手動で編集しません。

4. ファイル本体だけを「下書き」から「提出用」へ移動します。

   「下書き」に企画書.txtが残っていないことを確認します。残っていればコピーになっています。

5. 同じショートカットを開き、開いたファイルのパスと判別用の文字を記録して閉じます。

   アプリがフルパスを表示できる場合は、その表示で実際の対象を確認します。タイトルにファイル名だけが出る場合、名前だけでは保存場所を確認したことになりません。

6. 提出用のファイル本体を提案書.txtへ改名し、同じショートカットからもう一度開いて結果を記録します。

   開けなかった場合は、表示されたエラーや対象の不在を記録します。移動先を手動で指定して開いた結果は、自動で見つけた結果と分けます。

追跡または探索で移動先を見つけられた場合、提出用のファイルが開きます。開けない結果もあり得ます。成功だけでは、Object IDによる追跡が使われたのか、特徴による探索が使われたのかは判定できません。

元のパスの再利用を試す

前の試行とは別の新しい検証専用フォルダー、ファイル、ショートカットで最初からやり直します。一度解決したショートカットはリンク情報が更新され得るので、使い回すと比較の条件がそろいません。移動前のファイルには「元ファイル」、代わりに置くファイルには「別ファイル」と異なる文字を保存します。Resolveの更新条件

flowchart TB
    accTitle: 元のパスを別ファイルで再利用する手順の流れ
    accDescr: 元ファイルを移動したあと、ショートカットを開く前に元のパスへ同じ名前の別ファイルを置き、開いたファイルがどちらかを記録します。
    A["元ファイルを移動する"] --> B["元のパスに別ファイルを置く"]
    B --> C["ショートカットを開く"]
    C --> D["どちらが開いたか記録"]

図11: 別ファイルを置くまでショートカットは開かず、開いたあとに判別用の文字で見分けます。

1. 新しい「下書き」に元ファイルを作り、そのショートカットから開けることを確認して閉じます。

2. 元ファイル本体を「提出用」へ移動します。

   ここではまだショートカットを開かないでください。

3. 空いた元のパスに、同じ名前で内容の異なる別ファイルを新規作成します。

   移動した元ファイルは削除・上書きせずに残します。

4. ショートカットを開き、パスと判別用の文字から、どちらのファイルが開いたかを記録します。

古いパスの「別ファイル」が開けば、この条件ではショートカットの解決が移動した元ファイルの選択を保証しなかったと分かります。ほかの結果になっても、環境や条件を省略して一般化しないでください。

試行条件と解決結果

確かめるのは古い場所が使えなくなったあとに、どの対象へたどり着いたかです。「開けたか」「正しい対象か」「内部でどの探索経路を使ったか」は別々の問いです。

開けない場合は、まず移動先に本体が存在し、直接開けるかを確認します。そのうえで条件と失敗結果を記録してください。自動追跡を成立させるためにObject IDや管理ポリシーを変更しないでください。実務でショートカットを直す場合は、正しい本体だと確認してから新しいショートカットを作り、もう一度対象を確認します。

アプリからの解決

COMを初期化してIShellLinkWとIPersistFileを扱うWindowsデスクトップアプリの開発者に向けた節です。

APIでリンク先を解決する

検証用の.lnkを使い、UIの表示、探索の時間、リンク情報の更新をどう扱うかを先に決めます。初期化と解放を含む具体的な例はShell LinksのUsing Shell Linksを参照してください。

1. IPersistFile::Loadでショートカットを読み込み、戻り値を確認します。

2. 目的に合ったフラグでIShellLinkW::Resolveを呼び出し、成功を確認します。

   失敗した場合はHRESULTを記録し、解決後のパスが得られたものとして処理を続けません。IShellLinkW::Resolve

3. IShellLinkW::GetPathでパスを取得し、取得結果と対象を確認します。

   GetPathはパスの取得で、見失ったファイルを探し直す操作ではありません。S_FALSEは空のパスが返る場合の戻り値なので、取得できたものとして扱わないでください。IShellLinkW::GetPath

解決とパスの取得に成功した場合、解決後のパスを得られます。ただし、その成功を業務上意図した元のファイルであることの証明とは扱いません。

flowchart TB
    accTitle: ショートカットを読み込んでからリンク先を解決する
    accDescr: IPersistFileでリンクを読み込み、Resolveで解決を試みて成功を確認した後にGetPathで解決後のパスを取得します。
    L["リンクを読み込む"] --> R["Resolveで解決を試す"]
    R -->|"成功を確認"| G["GetPathでパスを得る"]

図12: 移動先を探すのはResolveです。元の場所の文字列を読むだけでは探せません。

Resolveのフラグを確認する

主な指定を次の表に示します。フラグは目的に応じて選び、「どれでも開ければ成功」としないことが大切です。正確な更新条件や組み合わせはResolveのAPIリファレンスで確認します。

既存のAPI検証結果

初版で公開した検証記録（JSON）には対象環境と次の観測が残っています。これは既存の記録の説明で、この改稿でWindows上の再測定を行ったという意味ではありません。

各試行で、得られたパスの対象は存在していました。記録には移動前後でファイルIDが一致し、コピーと差し替えたファイルのIDは異なること、コピーの内容が元と同じであることも残っています。このファイルIDの観測を、追跡用Object IDを実際に使った証拠とは扱いません。

この一環境では、移動・改名後は新しいパスが得られた一方、元の場所に別ファイルを置くと古いパスが得られました。Windows 11のエクスプローラーでの動作や、Resolve内部の探索経路は、この記録からは確認できません。

flowchart TB
    accTitle: 既存の検証記録で得られたパス
    accDescr: Windows Server 2025の一環境では、移動と改名のあとのResolveで新しいパスが得られ、別の試行で元のパスに別ファイルを置いたあとのResolveでは古いパスが得られました。
    M["移動・改名後のResolve"] --> N["新しいパス"]
    N -.-|"別の試行"| R["元のパスに別ファイル"]
    R --> O["古いパス"]

図13: この記録は一環境の観測で、どの探索経路を通ったかは分かりません。

追跡と探索の制限

追跡・探索の実行条件

追跡情報を利用できること、対象へアクセスできること、必要な探索が許可されていることなどが結果に関わります。APIではフラグで、管理された環境ではNoResolveTrackやNoResolveSearchのポリシーで、追跡や探索を制限できます。開けなかったことだけを、ファイルが消えた証拠やObject IDが壊れた証拠とは扱えません。ADMX_StartMenu Policy CSP

flowchart TB
    accTitle: 追跡と探索を制限する設定
    accDescr: APIのフラグと管理ポリシーのどちらでも、ショートカットの追跡や探索を制限できます。
    F["APIのフラグ"] --> L["追跡や探索を制限"]
    G["管理ポリシー"] --> L

図14: 追跡や探索は、APIのフラグでも管理ポリシーでも制限できます。

別ボリューム・別PCへの移動

同一NTFSボリュームでの確認結果を、USB、別ボリューム、別PC、同期・ネットワーク環境へ一般化しないでください。別の場所まで追跡できる条件はありますが、常に見つかるわけではありません。また、ショートカットだけを渡しても、リンク先のファイル本体が一緒に渡るわけではありません。分散リンク追跡の機能と制約

flowchart TB
    accTitle: ショートカットだけを渡したとき
    accDescr: ショートカットだけを別のPCへ渡しても、リンク先のファイル本体は一緒に渡りません。
    S["ショートカットだけを渡す"] --> N["リンク先の本体は渡らない"]

図15: ショートカットは本体の代わりにはなりません。

Object IDの変更

Object IDを手で書き換える必要はありません。MicrosoftはObject IDの変更・削除が分散リンク追跡などに問題を起こし得ると警告しています。fsutil objectid

シンボリックリンクとの違い

.lnkはシェルが読み取ってリンク先を解決するファイルです。シンボリックリンクはファイルシステムのパス解決に関わる別の仕組みです。「リンク」という名前が共通でも、ここで説明した追跡や探索をそのまま当てはめることはできません。Symbolic Links

関連記事

USBの安全な取り外しと書き込みキャッシュ

参考資料

Microsoftの一次資料と、初版で公開した検証記録です。本文中の各主張の近くからも対応する資料へリンクしています。

• Microsoft Learn, Shell Links。通常のショートカットの保存情報、リンク解決の大筋、COMを使う例。
• Microsoft Learn, IShellLinkW::Resolve。追跡と特徴による探索、各種フラグ、リンク情報の更新条件。
• Microsoft Learn, Distributed Link Tracking and Object Identifiers。Object ID、コピーとの違い、NTFSの追跡と制約。
• Microsoft Open Specifications, ShellLinkHeader。リンク先の属性・時刻・サイズの保存形式。
• Microsoft Open Specifications, TrackerDataBlock。リンク先の探索に渡す追跡用追加データ。
• Microsoft Learn, ADMX_StartMenu Policy CSP。NoResolveTrackとNoResolveSearchによる追跡・探索の制御。
• Microsoft Learn, IShellLinkW::GetPath。リンク先パスの取得と戻り値。
• Microsoft Learn, GetFileInformationByHandle。ファイルIDとボリューム識別情報による比較、および識別子の制約。
• Microsoft Learn, fsutil objectid。追跡用Object IDと出生時の識別情報、識別子の不用意な変更への警告。
• Microsoft Learn, Symbolic Links。.lnkとは異なるファイルシステムのリンク。
• ショートカットの移動追跡の検証記録（JSON）。Windows Server 2025の一環境で観測したAPIの結果。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

元のファイルを移動してもショートカットが開けるのはなぜですか？

通常の.lnkショートカットは、保存したパスでリンク先を見つけられない場合に、利用できる追跡情報やファイルの特徴を使って探し直せるためです。単なるパス文字列ではありません。ただし、ファイルシステムや設定、探索の条件によっては見つからないこともあります。

ショートカットはファイルの内容を比較して元のファイルを探しますか？

ここで説明するリンク解決は、パス、NTFSの追跡用識別情報、名前や作成日時などを使います。内容の一致によって元のファイルであることを証明する仕組みではありません。同じ内容をコピーしても、そのコピーは別のファイルです。

元の場所に同じ名前の別ファイルを置くと、移動した元ファイルを開きますか？

必ず元のファイルを開くとは限りません。通常のリンク解決では保存されたパスの確認が先なので、元の場所の別ファイルがリンク先として扱われる可能性があります。自動追跡を、特定のファイルを必ず選ぶ保証として使わないでください。

USBや別のPCへ移しても必ず追跡できますか？

保証されません。NTFSの追跡と特徴による探索は別の仕組みであり、移動先のファイルシステム、残っている追跡情報、サービスやポリシー、接続状態などが関わります。ショートカットだけを渡しても、リンク先のファイル本体が一緒に渡るわけではありません。

ショートカットとシンボリックリンクは同じですか？

異なります。.lnkはWindowsのシェルが読み取ってリンク先を解決するためのファイルです。シンボリックリンクはファイルシステムのパス解決に関わる別の仕組みであり、.lnkの探索動作がそのまま当てはまるわけではありません。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。