Comment un raccourci Windows retrouve-t-il un fichier déplacé ? — L'emplacement d'un fichier et son identité sont deux choses distinctes

Vous avez créé un raccourci sur le Bureau pour ouvrir un projet rangé dans le dossier Brouillons. Plus tard, vous avez déplacé ce projet vers le dossier Remise.

Vous n’avez pas recréé le raccourci. Pourtant, un double-clic peut encore ouvrir le projet à son nouvel emplacement.

Pourquoi retrouve-t-il un fichier qui n’est plus là où il était ?

Un raccourci retient plus qu’un emplacement. Il peut aussi transporter des informations permettant de rechercher à nouveau une cible qu’il ne trouve plus. Cet article suit cette recherche, à l’aide d’un .lnk ordinaire pointant vers un fichier régulier.¹

1. Regardez d’abord à l’ancien emplacement

Supposons que vous déplaciez le projet de C:\Work\Brouillons\projet.txt vers C:\Work\Remise\projet.txt sur le même volume NTFS.

Il n’y a toujours qu’un seul fichier, et seul son emplacement a changé. Le chemin enregistré dans le raccourci, lui, pointe toujours vers Brouillons.

flowchart TB
    accTitle: Le déplacement du projet sépare l'ancien chemin de son emplacement actuel
    accDescr: Le dossier Brouillons dont le raccourci se souvient ne contient plus le projet, et le même projet est passé dans le dossier Remise.
    L["Raccourci"] --> O["Brouillons - il n'y est plus"]
    F["Le même projet"] --> N["Remise - il est ici"]

Figure 1 : Un mécanisme qui suivrait uniquement l’ancien emplacement se heurterait ici à une impasse.

Le shell Windows vérifie lui aussi d’abord si la cible se trouve à l’emplacement enregistré. Il n’abandonne pourtant pas forcément dès qu’il ne l’y trouve pas. Un traitement se poursuit, qui recherche à nouveau avec les informations disponibles. C’est ce qu’on appelle la résolution de lien.²

Le format de fichier .lnk contient plus que des informations décrivant l’emplacement de la cible. Il comporte aussi des champs qui enregistrent des éléments comme la date de création et la taille, et, par-dessus, des blocs de données supplémentaires porteurs d’informations de suivi sont définis. L’unique ligne affichée comme Cible dans la boîte de dialogue des propriétés n’est pas tout ce que contient un raccourci.³⁴

Sur quoi s’appuie-t-il alors lorsque le nom a changé lui aussi ?

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (5 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Une étiquette nominative qui survit à un renommage

Renommez maintenant en proposition.txt le projet déplacé vers Remise. L’emplacement et le nom ont tous deux changé, mais vous avez déplacé et renommé le fichier d’origine plutôt que d’en créer un autre.

Ce qui aide dans une telle situation, ce sont des identifiants indépendants de l’emplacement et du nom.

Le mécanisme Windows appelé suivi de liens distribués utilise l’ID d’objet attaché à un fichier ou à un dossier sur NTFS. Un ID d’objet n’est pas un attribut obligatoire ; il équivaut à une étiquette nominative qui identifie un élément à suivre. Un index permettant de rechercher les ID d’objet au sein de ce volume est également fourni.⁵

Supposons par exemple que le projet porte l’étiquette K. K est un symbole pour cette explication, pas le format réel d’un identifiant.

flowchart TB
    accTitle: Des identifiants qui survivent à un déplacement et à un renommage sur un même volume
    accDescr: Lorsque les informations de suivi sont conservées, la même étiquette nominative est l'indice permettant de suivre le projet de Brouillons jusqu'à la proposition de Remise, bien que le nom et l'emplacement aient changé.
    A["projet.txt avec l'étiquette K"] -->|"Déplacement et renommage"| B["proposition.txt avec l'étiquette K"]
    L["Informations de suivi dans le raccourci"] -.->|"Recherche avec K comme indice"| B

Figure 2 : L’emplacement d’un fichier peut changer sans que changent les identifiants utilisés pour le suivi.

Lorsque des informations de suivi sont disponibles, la recherche ne se limite pas à traquer l’ancien nom dans tous les dossiers ; la cible après le déplacement peut être retrouvée à partir des identifiants. Le TrackerDataBlock d’un .lnk peut stocker les informations transmises à ce service de suivi.⁴

Changer d’adresse ne fait pas de vous une autre personne. De la même façon, le chemin d’un fichier peut changer tandis que les indices permettant de suivre le même fichier subsistent. C’est l’une des raisons pour lesquelles un raccourci s’ouvre encore après un déplacement.

Tous les raccourcis ne sont pourtant pas résolus ainsi. Lorsque l’étiquette nominative ne peut pas être utilisée, la recherche passe à une autre méthode.

3. Quand l’identifiant ne trouve rien, la recherche se fait par caractéristiques

Et si un dossier voisin contenait un fichier ayant la même date de création que le projet d’origine et des attributs similaires ? Cela en ferait un candidat susceptible d’être le fichier d’origine sous un nouveau nom.

Le shell dispose aussi d’une recherche qui utilise de telles caractéristiques. La description officielle indique que, lorsque le service de suivi est indisponible ou que le suivi ne trouve pas la cible, le shell cherche dans des endroits comme le dossier d’origine et ses environs des candidats dont le nom, la date de création, etc., correspondent.²

Le parcours suivi jusqu’ici peut se résumer ainsi.

flowchart TB
    accTitle: L'indice se déplace de l'emplacement enregistré vers le suivi puis vers les caractéristiques
    accDescr: Si la cible n'est pas à l'emplacement enregistré, les informations de suivi disponibles sont essayées, et si cela ne la trouve toujours pas, une recherche par caractéristiques est tentée.
    P["Vérifier l'emplacement enregistré"] -->|"Introuvable"| I["Utiliser les informations de suivi"]
    I -->|"Indisponible ou introuvable"| S["Chercher des candidats aux caractéristiques concordantes"]

Figure 3 : Les grandes lignes de la résolution de lien ordinaire. Le fait que le suivi et la recherche aient lieu dépend aussi des paramètres et de la manière dont l’appel est effectué.

Une étiquette nominative concordante et des caractéristiques similaires ne sont pas des preuves d’égale valeur. Si plusieurs fichiers partagent un nom ou une date de création, les caractéristiques seules ne peuvent pas prouver lequel est la véritable cible. Ce n’est pas un mécanisme qui compare tout le contenu pour prouver l’identité ; c’est un mécanisme qui recherche à nouveau une cible perdue.

La recherche ne se poursuit pas non plus sans limite. Une application peut indiquer des indicateurs qui suppriment le suivi ou la recherche, et une stratégie d’administration peut les restreindre. Le fait que le fichier se soit ouvert ne vous dit pas, à lui seul, quel indice a fait le travail.⁶

4. Une copie au contenu identique est-elle le même fichier ?

Copiez maintenant proposition.txt de Remise vers Diffusion. Le contenu est le même, mais il y a désormais deux fichiers. Modifiez-en un seul et l’autre conserve son contenu.

L’ID d’objet n’est pas non plus simplement dupliqué par une copie ordinaire. Si deux fichiers du même volume avaient le même identifiant, l’étiquette nominative ne pourrait plus les distinguer. Microsoft explique qu’une copie n’hérite pas du même ID d’objet que l’original.⁵

flowchart TB
    accTitle: Déplacer un fichier et le copier n'ont pas le même sens pour l'identité
    accDescr: Là où le déplacement conserve le même fichier, une copie ordinaire crée un fichier distinct qui porte le contenu, et l'ID d'objet de suivi d'origine n'est pas dupliqué tel quel.
    O["La proposition d'origine"] -->|"Copie ordinaire"| C["Un fichier de proposition distinct"]
    O --> A["L'étiquette nominative d'origine"]
    C --> B["N'hérite pas de la même étiquette"]

Figure 4 : Rendre le contenu identique n’équivaut pas à déplacer le fichier d’origine lui-même.

Voici encore un cas qui prend les gens au dépourvu. Une fois le projet d’origine déplacé vers Remise, que se passe-t-il si un autre fichier du même nom est placé à l’emplacement désormais vacant Brouillons\projet.txt ?

Comme l’a décrit la section 1, l’emplacement enregistré est normalement vérifié en premier. Si une cible y est trouvée, le processus peut ne jamais atteindre l’étape de recherche du nouvel emplacement. Autrement dit, même avec le suivi en place, rien ne garantit que le fichier d’origine que vous avez déplacé soit celui qui est choisi.¹

Un raccourci est un point d’entrée commode pour trouver une cible qu’il peut ouvrir maintenant. Ce n’est pas un mécanisme destiné à prouver, à chaque fois, qu’il s’agit du même fichier qu’auparavant. Une fois cette distinction acquise, la commodité et les limites s’emboîtent.

5. Suivez le même fichier sur votre propre PC

Si vous essayez, utilisez un fichier texte créé dans un dossier de test local plutôt qu’un document de travail. Commencez par créer Brouillons et Remise sur le même volume NTFS, et gardez les conditions étroites en évitant les dossiers synchronisés et les partages réseau.

Créez un fichier dans Brouillons, créez-en un raccourci et vérifiez qu’il s’ouvre depuis là. Déplacez ensuite le seul fichier vers Remise et ouvrez le raccourci. Renommez enfin le fichier et réessayez. Vérifiez chaque fois quel fichier s’est réellement ouvert.

Ce que vous observez, c’est si le raccourci atteint le nouvel emplacement une fois que l’ancien n’est plus utilisable. S’il ne s’ouvre pas, cela ne contredit pas cet article. Le résultat change selon les conditions dans lesquelles le suivi NTFS est disponible, les informations qui subsistent, les paramètres, etc. N’attendez pas le même résultat une fois qu’un fichier est passé sur une clé USB ou sur un autre PC.⁵⁶

En rédigeant cet article, j’ai également confirmé le comportement avec IShellLinkW::Resolve sur du NTFS local sous Windows Server 2025 (build 26100). Après un déplacement et un renommage, le nouveau chemin a été renvoyé, et lors d’un essai distinct où un autre fichier était placé à l’emplacement d’origine, c’est l’ancien chemin qui a été renvoyé. Il s’agit d’une observation de l’API dans un environnement, pas d’un test via l’interface de l’Explorateur de fichiers sous Windows 11 ni d’une vérification du chemin de recherche interne utilisé. Le relevé d’observation est également disponible.

Pour effectuer la comparaison où un autre fichier est placé à l’emplacement d’origine, recommencez de zéro avec un autre fichier de test. Un raccourci déjà résolu peut avoir vu ses informations de lien mises à jour, si bien que réutiliser le même raccourci peut signifier qu’il ne pointe plus vers l’ancien emplacement.²

6. Pour les développeurs : lire un chemin ou rechercher à nouveau

Lorsqu’une application travaille avec un .lnk, distinguez la lecture des informations enregistrées de la recherche d’une cible perdue. Obtenir le chemin avec GetPath sur IShellLink et tenter la résolution de lien avec Resolve ne sont pas la même opération.⁷

flowchart TB
    accTitle: Charger le raccourci puis résoudre la cible
    accDescr: Charger le lien avec IPersistFile, tenter la résolution avec Resolve et obtenir le chemin résolu avec GetPath après avoir confirmé la réussite.
    L["Charger le lien"] --> R["Tenter la résolution avec Resolve"]
    R -->|"Confirmer la réussite"| G["Obtenir le chemin avec GetPath"]

Figure 5 : Lire la chaîne de l’emplacement d’origine n’équivaut pas à avoir recherché le nouveau.

Dans un traitement automatisé, l’interface affichée lorsque rien n’est trouvé, le temps consacré à la recherche, le recours au suivi et la mise à jour des informations de lien sont eux aussi des décisions de conception. Par exemple, SLR_NOSEARCH supprime la recherche par caractéristiques et SLR_NOTRACK supprime le recours au suivi de liens distribués. Choisissez les indicateurs selon votre objectif et ne considérez pas comme un succès le fait d’avoir ouvert n’importe quoi.²

Notez que l’ID d’objet de suivi et l’ID de fichier obtenu depuis un handle de fichier ne sont pas le même élément. La comparaison d’ID de fichier fait aussi intervenir le volume. Ne les confondez pas sous prétexte que les deux s’appellent un ID ; vérifiez de quel identifiant, issu de quelle API, il s’agit. Il n’est pas nécessaire de réécrire un ID d’objet à la main.⁸⁹

Par ailleurs, le .lnk dont il est question ici est un fichier du shell. Il diffère d’un lien symbolique, qui opère au sein de la résolution de chemin du système de fichiers, si bien que cette description de la recherche ne s’y transpose pas telle quelle.¹⁰

Un raccourci retient plus que l’ancienne adresse. Si l’emplacement ne trouve pas le fichier, il utilise les informations de suivi, et si celles-ci sont inutilisables, il recherche par caractéristiques. C’est pourquoi il peut parfois suivre un déplacement ou un renommage. Et dès que des copies au contenu identique, ou un autre fichier placé à l’emplacement d’origine, entrent en jeu, il ne peut pas toujours désigner la cible d’origine.

Articles liés

• Le retrait sécurisé d’une clé USB et le cache d’écriture

Liens de référence

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Pourquoi un raccourci s'ouvre-t-il encore après le déplacement du fichier d'origine ?

Parce qu'un raccourci .lnk ordinaire peut effectuer une nouvelle recherche, à l'aide des informations de suivi disponibles et des caractéristiques du fichier, lorsque le chemin enregistré ne trouve pas la cible. Ce n'est pas une simple chaîne de caractères. Selon le système de fichiers, les paramètres et les conditions de la recherche, la cible peut toutefois rester introuvable.

Un raccourci compare-t-il le contenu des fichiers pour retrouver le fichier d'origine ?

La résolution de lien décrite ici utilise le chemin, l'identifiant de suivi NTFS et des éléments comme le nom et la date de création. Ce n'est pas un mécanisme qui prouve par comparaison de contenu qu'un fichier est bien l'original. Même si vous copiez un contenu identique, cette copie est un autre fichier.

Si un autre fichier du même nom est placé à l'emplacement d'origine, l'original déplacé sera-t-il ouvert ?

Pas nécessairement. La résolution de lien ordinaire vérifie d'abord le chemin enregistré, si bien que l'autre fichier situé à l'emplacement d'origine peut être traité comme la cible. Ne comptez pas sur le suivi automatique comme garantie qu'un fichier précis sera toujours choisi.

Le suivi est-il garanti après le déplacement d'un fichier vers une clé USB ou un autre PC ?

Non, ce n'est pas garanti. Le suivi NTFS et la recherche par caractéristiques sont des mécanismes distincts, et le système de fichiers de destination, les informations de suivi qui subsistent, les services et stratégies ainsi que l'état de la connexion entrent tous en jeu. Remettre à quelqu'un le seul raccourci ne lui remet pas le fichier cible lui-même.

Un raccourci et un lien symbolique sont-ils la même chose ?

Non, ils sont différents. Un .lnk est un fichier que le shell Windows lit pour résoudre la cible. Un lien symbolique est un mécanisme distinct qui participe à la résolution de chemin du système de fichiers, et le comportement de recherche d'un .lnk ne s'y transpose pas.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.