Come fa un collegamento di Windows a trovare un file spostato? — La posizione di un file e la sua identità sono due cose diverse
· Aggiornato il: · Go Komura · Windows, File system, NTFS
Avete creato sul desktop un collegamento per aprire una bozza di progetto conservata nella cartella Bozze. In seguito avete spostato il progetto nella cartella Consegna.
Il collegamento non l’avete ricreato. Eppure, con un doppio clic, può ancora aprire il progetto nella sua nuova posizione.
Perché riesce a trovare un file che non è più dove si trovava?
Un collegamento ricorda più di una posizione. Può anche portare con sé informazioni per cercare di nuovo una destinazione che non riesce più a trovare. Questo articolo segue quella ricerca, usando un normale .lnk che punta a un file regolare.1
1. Guardate prima nella vecchia posizione
Supponiamo che spostiate il progetto da C:\Work\Bozze\progetto.txt a C:\Work\Consegna\progetto.txt sullo stesso volume NTFS.
Il file resta uno soltanto, ed è cambiata solo la sua collocazione. Il percorso memorizzato nel collegamento, però, punta ancora a Bozze.
flowchart TB
accTitle: Lo spostamento del progetto separa il vecchio percorso dalla sua posizione attuale
accDescr: La cartella Bozze che il collegamento ricorda non contiene più il progetto, e lo stesso progetto si è spostato nella cartella Consegna.
L["Collegamento"] --> O["Bozze - non è più lì"]
F["Lo stesso progetto"] --> N["Consegna - è qui"]
Figura 1: Un meccanismo che seguisse solo la vecchia posizione si troverebbe qui in un vicolo cieco.
Anche la shell di Windows controlla per prima cosa se la destinazione si trova nella posizione memorizzata. Non rinuncia però necessariamente nel momento in cui non la trova lì. Prosegue un’elaborazione che cerca di nuovo con tutte le informazioni disponibili. È ciò che si chiama risoluzione del collegamento.2
Il formato di file .lnk contiene più delle informazioni che descrivono dove si trova la destinazione. Ha anche campi che registrano elementi come la data di creazione e la dimensione, e su questa base sono definiti blocchi di dati aggiuntivi che trasportano informazioni di rilevamento. L’unica riga mostrata come Destinazione nella finestra delle proprietà non è tutto ciò che un collegamento contiene.34
Su che cosa si basa allora quando è cambiato anche il nome?
Nel diagramma, una linea continua indica una relazione che vale sempre e una linea tratteggiata indica una relazione condizionale (le condizioni sono nella spiegazione di ciascuna relazione nella pagina di dettaglio). L’elenco completo delle relazioni (in totale 5, con evidenza e livello di certezza) e le definizioni dei concetti principali sono raccolti nella pagina di dettaglio della mappa della conoscenza (in giapponese). Dati: JSON-LD / Turtle
2. Una targhetta col nome che sopravvive a una rinomina
Rinominate ora in proposta.txt il progetto spostato in Consegna. Posizione e nome sono cambiati entrambi, ma avete spostato e rinominato il file originale invece di crearne uno diverso.
Ciò che aiuta in una situazione simile sono identificatori indipendenti da posizione e nome.
Il meccanismo di Windows chiamato rilevamento collegamenti distribuiti usa l’ID oggetto associato a un file o a una cartella su NTFS. Un ID oggetto non è un attributo obbligatorio; equivale a una targhetta col nome che identifica un elemento da seguire. Viene fornito anche un indice per cercare gli ID oggetto all’interno di quel volume.5
Supponiamo per esempio che il progetto porti la targhetta K. K è un simbolo usato per questa spiegazione, non il formato reale di un identificatore.
flowchart TB
accTitle: Identificatori che sopravvivono a uno spostamento e a una rinomina su un unico volume
accDescr: Quando le informazioni di rilevamento sono conservate, la stessa targhetta col nome è l'indizio per seguire il progetto in Bozze fino alla proposta in Consegna nonostante nome e posizione siano cambiati.
A["progetto.txt con targhetta K"] -->|"Spostamento e rinomina"| B["proposta.txt con targhetta K"]
L["Informazioni di rilevamento nel collegamento"] -.->|"Ricerca con K come indizio"| B
Figura 2: La posizione di un file può cambiare senza che cambino gli identificatori usati per il rilevamento.
Quando sono disponibili informazioni di rilevamento, la ricerca non si limita a inseguire il vecchio nome in tutte le cartelle; la destinazione dopo lo spostamento può essere trovata a partire dagli identificatori. Il TrackerDataBlock di un .lnk può memorizzare le informazioni consegnate a questo servizio di rilevamento.4
Cambiare indirizzo non vi rende un’altra persona. Allo stesso modo, il percorso di un file può cambiare mentre restano gli indizi per seguire lo stesso file. È una delle ragioni per cui un collegamento si apre ancora dopo uno spostamento.
Non tutti i collegamenti vengono però risolti così. Quando la targhetta col nome non è utilizzabile, la ricerca passa a un altro metodo.
3. Quando l’identificatore non trova nulla, si cerca per caratteristiche
E se una cartella vicina contenesse un file con la stessa data di creazione del progetto originale e attributi simili? Sarebbe un candidato che potrebbe essere il file originale sotto un nuovo nome.
La shell dispone anche di una ricerca che usa caratteristiche di questo tipo. La descrizione ufficiale dice che, quando il servizio di rilevamento non è disponibile o il rilevamento non trova la destinazione, la shell cerca in luoghi come la cartella originale e i suoi dintorni candidati il cui nome, data di creazione e così via corrispondano.2
Il percorso seguito finora si può riassumere così.
flowchart TB
accTitle: L'indizio si sposta dalla posizione memorizzata al rilevamento e poi alle caratteristiche
accDescr: Se la destinazione non è nella posizione memorizzata, si provano le informazioni di rilevamento disponibili, e se nemmeno queste la trovano, si tenta una ricerca per caratteristiche.
P["Controllare la posizione memorizzata"] -->|"Non trovata"| I["Usare le informazioni di rilevamento"]
I -->|"Non disponibili o non trovata"| S["Cercare candidati con caratteristiche corrispondenti"]
Figura 3: Le linee generali della normale risoluzione del collegamento. Che rilevamento e ricerca avvengano dipende anche dalle impostazioni e dal modo in cui viene effettuata la chiamata.
Una targhetta corrispondente e caratteristiche simili non sono prove ugualmente solide. Se più file condividono un nome o una data di creazione, le sole caratteristiche non possono dimostrare quale sia la vera destinazione. Non è un meccanismo che confronta tutto il contenuto per dimostrare l’identità; è un meccanismo che cerca di nuovo una destinazione perduta.
Nemmeno la ricerca prosegue senza limiti. Un’applicazione può indicare flag che sopprimono il rilevamento o la ricerca, e un criterio amministrativo può limitarli. Il fatto che il file si sia aperto non vi dice di per sé quale indizio abbia fatto il lavoro.6
4. Una copia con lo stesso contenuto è lo stesso file?
Copiate ora proposta.txt da Consegna a Distribuzione. Il contenuto è lo stesso, ma ora i file sono due. Modificatene uno solo e l’altro conserva il proprio contenuto.
Nemmeno l’ID oggetto viene semplicemente duplicato da una copia ordinaria. Se due file sullo stesso volume avessero lo stesso identificatore, la targhetta col nome non potrebbe più distinguerli. Microsoft spiega che una copia non eredita lo stesso ID oggetto dell’originale.5
flowchart TB
accTitle: Spostare un file e copiarlo significano cose diverse per l'identità
accDescr: Mentre lo spostamento mantiene lo stesso file, una copia ordinaria crea un file distinto che contiene il contenuto, e l'ID oggetto di rilevamento originale non viene duplicato tale e quale.
O["La proposta originale"] -->|"Copia ordinaria"| C["Un file di proposta distinto"]
O --> A["La targhetta originale"]
C --> B["Non eredita la stessa targhetta"]
Figura 4: Rendere il contenuto identico non equivale a spostare il file originale stesso.
Ecco un altro caso che coglie le persone alla sprovvista. Dopo che il progetto originale è stato spostato in Consegna, che cosa accade se un file diverso con lo stesso nome viene messo nella posizione ora libera Bozze\progetto.txt?
Come descritto nella sezione 1, normalmente si controlla per prima la posizione memorizzata. Se lì viene trovata una destinazione, il procedimento può non arrivare mai alla fase di ricerca della nuova posizione. In altre parole, anche con il rilevamento attivo non c’è alcuna garanzia che venga scelto il file originale che avete spostato.1
Un collegamento è un comodo punto d’ingresso per trovare una destinazione che può aprire adesso. Non è un meccanismo per dimostrare, ogni volta, che si tratta dello stesso file di prima. Una volta assimilata questa distinzione, comodità e limiti si incastrano.
5. Seguite lo stesso file sul vostro PC
Se volete provare, usate un file di testo creato in una cartella di prova locale anziché un documento di lavoro. Iniziate creando Bozze e Consegna sullo stesso volume NTFS e mantenete condizioni ristrette evitando cartelle sincronizzate e condivisioni di rete.
Create un file in Bozze, createne un collegamento e verificate che si apra da lì. Spostate poi il solo file in Consegna e aprite il collegamento. Rinominate infine il file e riprovate. Ogni volta controllate quale file si sia effettivamente aperto.
Ciò che state osservando è se il collegamento raggiunga la nuova posizione una volta che la vecchia non è più utilizzabile. Se non si apre, ciò non contraddice questo articolo. Il risultato cambia con le condizioni in cui il rilevamento NTFS è disponibile, con le informazioni rimaste, con le impostazioni e così via. Non aspettatevi lo stesso risultato una volta che un file passa su una chiavetta USB o su un altro PC.56
Mentre scrivevo ho verificato il comportamento anche con IShellLinkW::Resolve su NTFS locale sotto Windows Server 2025 (build 26100). Dopo uno spostamento e una rinomina è tornato il nuovo percorso, e in una prova separata in cui un file diverso era collocato nella posizione originale è tornato il vecchio percorso. È l’osservazione dell’API in un ambiente, non un test tramite l’interfaccia di Esplora file su Windows 11 né una verifica di quale percorso di ricerca interno sia stato usato. È disponibile anche il registro delle osservazioni.
Per eseguire il confronto in cui un file diverso è collocato nella posizione originale, ricominciate da zero con un altro file di prova. Un collegamento già risolto può aver visto aggiornate le proprie informazioni di collegamento, quindi riutilizzare lo stesso collegamento può significare che non punta più alla vecchia posizione.2
6. Per chi sviluppa: leggere un percorso oppure cercare di nuovo
Quando un’applicazione lavora con un .lnk, tenete distinta la lettura delle informazioni memorizzate dalla ricerca di una destinazione perduta. Ottenere il percorso con GetPath su IShellLink e tentare la risoluzione del collegamento con Resolve non sono la stessa operazione.7
flowchart TB
accTitle: Caricare il collegamento e poi risolvere la destinazione
accDescr: Caricare il collegamento con IPersistFile, tentare la risoluzione con Resolve e ottenere il percorso risolto con GetPath dopo aver confermato l'esito positivo.
L["Caricare il collegamento"] --> R["Tentare la risoluzione con Resolve"]
R -->|"Confermare l'esito positivo"| G["Ottenere il percorso con GetPath"]
Figura 5: Leggere la stringa della posizione originale non equivale ad aver cercato quella nuova.
Nell’elaborazione automatica sono decisioni di progetto anche l’interfaccia mostrata quando non si trova nulla, il tempo dedicato alla ricerca, il ricorso al rilevamento e l’aggiornamento delle informazioni di collegamento. Per esempio SLR_NOSEARCH sopprime la ricerca per caratteristiche e SLR_NOTRACK sopprime il ricorso al rilevamento collegamenti distribuiti. Scegliete i flag in base al vostro scopo e non considerate un successo l’aver aperto qualcosa di qualunque tipo.2
Notate che l’ID oggetto di rilevamento e l’ID file ottenuto da un handle di file non sono lo stesso elemento. Il confronto degli ID file coinvolge anche il volume. Non metteteli insieme solo perché entrambi si chiamano ID; verificate di quale identificatore, proveniente da quale API, si tratti. Non c’è bisogno di riscrivere a mano un ID oggetto.89
Inoltre, il .lnk di cui si parla qui è un file della shell. È diverso da un collegamento simbolico, che opera all’interno della risoluzione dei percorsi del file system, quindi questa descrizione della ricerca non vi si trasferisce senz’altro.10
Un collegamento ricorda più del vecchio indirizzo. Se la posizione non trova il file, usa le informazioni di rilevamento, e se queste non sono utilizzabili cerca per caratteristiche. Per questo a volte riesce a seguire uno spostamento o una rinomina. E non appena entrano in gioco copie con lo stesso contenuto, o un file diverso collocato nella posizione originale, non può sempre individuare la destinazione originale.
Articoli correlati
Link di riferimento
-
Microsoft Learn, Shell Links. Le informazioni che un normale collegamento memorizza e le linee generali della risoluzione del collegamento. ↩ ↩2
-
Microsoft Learn, IShellLinkW::Resolve. Il rilevamento e la ricerca per caratteristiche, i vari flag e le condizioni per l’aggiornamento delle informazioni di collegamento. ↩ ↩2 ↩3 ↩4
-
Microsoft Open Specifications, ShellLinkHeader. Gli attributi della destinazione, le date e la dimensione memorizzati in un .lnk. ↩
-
Microsoft Open Specifications, TrackerDataBlock. I dati di rilevamento aggiuntivi consegnati alla ricerca della destinazione. ↩ ↩2
-
Microsoft Learn, Distributed Link Tracking and Object Identifiers. Gli ID oggetto, la differenza in caso di copia, il rilevamento NTFS e i suoi vincoli. ↩ ↩2 ↩3
-
Microsoft Learn, ADMX_StartMenu Policy CSP. Il controllo di rilevamento e ricerca con NoResolveTrack e NoResolveSearch. ↩ ↩2
-
Microsoft Learn, IShellLinkW::GetPath. L’ottenimento del percorso della destinazione. ↩
-
Microsoft Learn, GetFileInformationByHandle. Il confronto tramite ID file e informazioni identificative del volume, e i vincoli sugli identificatori. ↩
-
Microsoft Learn, fsutil objectid. L’ID oggetto di rilevamento e le informazioni identificative registrate alla creazione. Un avvertimento contro la modifica sconsiderata degli identificatori. ↩
-
Microsoft Learn, Symbolic Links. Un collegamento del file system diverso da un .lnk. ↩
Articoli correlati
Articoli recenti con gli stessi tag per approfondire argomenti vicini.
Le profondità dell'I/O di Windows (5ª puntata) — Struttura interna di NTFS: capire il file system dall'MFT
Quinta puntata della serie che spiega con i diagrammi la struttura interna di NTFS. Si organizzano, dal punto di vista dello sviluppatore...
OneDrive «File su richiesta» e le applicazioni aziendali — le ipotesi che i segnaposto spezzano e come affrontarle
Un CSV sul desktop non si apre, o l'importazione fallisce con «file non trovato»: la causa può essere Known Folder Move e File su richies...
Copia Shadow del volume (VSS): meccanismo e pratica — perché si può fare il backup dei file in uso
I file in uso non si possono copiare per via della violazione di condivisione: come fa allora il software di backup? Spieghiamo i ruoli d...
Le profondità dell'I/O di Windows (4ª puntata) — Cache Manager: quando il vostro WriteFile arriva sul disco
Quarta puntata della serie che spiega con i diagrammi il Cache Manager di Windows. Si organizzano la cache implementata come file mapping...
La «rimozione sicura» della chiavetta USB serve ancora? — Ragionarci a partire dalla rimozione rapida e dalla cache di scrittura
Si può sfilare la chiavetta USB appena finita la copia? La cache di scrittura, Rimozione rapida contro Prestazioni migliori, come control...
Argomenti correlati
Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.
Argomenti tecnici Windows
Portale su sviluppo Windows, analisi dei problemi e valorizzazione delle risorse esistenti.
Servizi collegati all’argomento
L’articolo è direttamente collegato ai servizi seguenti.
Sviluppo di applicazioni Windows
Applicazioni aziendali, integrazione di dispositivi e strumenti di comunicazione, dai requisiti allo sviluppo.
Domande frequenti
Domande che ricorrono nelle consulenze sull’argomento dell’articolo.
- Perché un collegamento si apre ancora dopo che il file originale è stato spostato?
- Perché un normale collegamento .lnk può cercare di nuovo, usando le informazioni di rilevamento disponibili e le caratteristiche del file, quando il percorso memorizzato non trova la destinazione. Non è una semplice stringa di percorso. A seconda del file system, delle impostazioni e delle condizioni della ricerca, però, la destinazione può restare introvabile.
- Un collegamento confronta il contenuto dei file per trovare quello originale?
- La risoluzione del collegamento qui descritta usa il percorso, l'identificatore di rilevamento NTFS e dati come il nome e la data di creazione. Non è un meccanismo che dimostra tramite confronto del contenuto che un file è l'originale. Anche copiando un contenuto identico, quella copia è un file diverso.
- Se all'indirizzo originale viene messo un altro file con lo stesso nome, verrà aperto l'originale spostato?
- Non necessariamente. La normale risoluzione del collegamento controlla prima il percorso memorizzato, quindi l'altro file nella posizione originale può essere trattato come destinazione. Non affidatevi al rilevamento automatico come garanzia che venga sempre scelto un file specifico.
- Il rilevamento è garantito dopo aver spostato un file su una chiavetta USB o su un altro PC?
- No, non è garantito. Il rilevamento NTFS e la ricerca per caratteristiche sono meccanismi distinti, e il file system di destinazione, le informazioni di rilevamento rimaste, i servizi e i criteri nonché lo stato della connessione entrano tutti in gioco. Consegnare a qualcuno soltanto il collegamento non gli consegna il file di destinazione.
- Un collegamento e un collegamento simbolico sono la stessa cosa?
- No, sono diversi. Un .lnk è un file che la shell di Windows legge per risolvere la destinazione. Un collegamento simbolico è un meccanismo distinto che partecipa alla risoluzione dei percorsi del file system, e il comportamento di ricerca di un .lnk non vi si trasferisce.
Profilo dell’autore
Pagina di presentazione dell’autore dell’articolo.
Go Komura
Rappresentante di KomuraSoft LLC
Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.