Как ярлык Windows находит перемещённый файл? — Местоположение файла и его идентичность — разные вещи

Вы создали на рабочем столе ярлык, чтобы открывать план, лежащий в папке «Черновики». Потом вы переместили план в папку «На_отправку».

Ярлык вы не пересоздавали. И всё же двойной щелчок по нему может открыть план уже на новом месте.

Почему удаётся найти файл, которого больше нет там, где он был?

Ярлык помнит не только место. Он может нести и сведения для того, чтобы заново искать цель, которую больше не находит. В этой статье мы разберём такой поиск на примере обычного .lnk, указывающего на обычный файл.¹

1. Сначала проверяется прежнее место

Предположим, вы переместили план из C:\Work\Черновики\план.txt в C:\Work\На_отправку\план.txt в пределах одного тома NTFS.

Файл остался один — изменилось только его место. Однако путь, сохранённый в ярлыке, по-прежнему указывает на «Черновики».

flowchart TB
    accTitle: Перемещение плана разделяет старый путь и текущее место
    accDescr: В папке «Черновики», которую помнит ярлык, плана уже нет, а тот же план переместился в папку «На_отправку».
    L["Ярлык"] --> O["Черновики — здесь его больше нет"]
    F["Тот же план"] --> N["На_отправку — он здесь"]

Рис. 1: Механизм, который идёт только по старому месту, здесь упёрся бы в тупик.

Оболочка Windows тоже сначала проверяет, есть ли цель по сохранённому месту. Правда, обнаружив, что там её нет, она не обязательно сразу сдаётся. Продолжается обработка, которая ищет заново, используя доступные сведения. Это называется разрешением ссылки.²

Формат файла .lnk хранит не только сведения о том, где находится цель. В нём есть и поля, куда записываются, например, время создания и размер, а поверх них определены дополнительные блоки данных, несущие сведения для отслеживания. Одна строка, показанная в свойствах как «Объект», — это не всё, что содержит ярлык.³⁴

Так на что же он опирается, если изменилось и имя?

2. Использование метки имени, которая переживает переименование

Теперь переименуйте план, перемещённый в «На_отправку», в предложение.txt. Изменились и место, и имя, но вы переместили и переименовали исходный файл, а не создали другой.

В такой ситуации помогает идентифицирующая информация, отдельная от места и имени.

Механизм Windows под названием распределённое отслеживание ссылок (distributed link tracking) использует Object ID, назначаемый файлу или папке на NTFS. Object ID не является обязательным атрибутом; это, по сути, метка имени, которая идентифицирует объект для отслеживания. Кроме того, для поиска Object ID в пределах этого тома предусмотрен индекс.⁵

Допустим, например, что у плана есть метка имени K. K — условное обозначение для этого объяснения, а не настоящий формат идентификатора.

flowchart TB
    accTitle: Идентифицирующая информация, которая переживает перемещение и переименование в пределах одного тома
    accDescr: Если сведения отслеживания сохранились, одна и та же метка имени служит подсказкой, чтобы проследить план в папке «Черновики» до предложения в папке «На_отправку», хотя имя и место изменились.
    A["план.txt с меткой имени K"] -->|"Перемещение и переименование"| B["предложение.txt с меткой имени K"]
    L["Сведения отслеживания в ярлыке"] -.->|"Поиск по подсказке K"| B

Рис. 2: Место файла может измениться, а идентифицирующая информация, используемая для отслеживания, — не обязательно вместе с ним.

Когда сведения отслеживания доступны, поиск не сводится к тому, чтобы гоняться за старым именем по всем папкам: цель после перемещения можно найти по идентифицирующей информации. TrackerDataBlock в .lnk может хранить сведения, передаваемые этой службе отслеживания.⁴

Смена адреса не делает вас другим человеком. Так же и путь файла может измениться, а подсказки, позволяющие отслеживать тот же файл, могут сохраниться. Это одна из причин, по которой ярлык открывается и после перемещения.

Однако не каждый ярлык разрешается этим способом. Если метку имени использовать нельзя, поиск переходит к другому методу.

3. Если идентификатор не находит, ищем по признакам

А если в соседней папке окажется файл с тем же временем создания, что у исходного плана, и с похожими атрибутами? Он становится кандидатом — возможно, это исходный файл под новым именем.

У оболочки есть и поиск, использующий такие признаки. В официальном описании сказано, что когда служба отслеживания недоступна или отслеживание не находит цель, оболочка ищет в таких местах, как исходная папка и её окрестности, кандидатов, у которых совпадают имя, время создания и тому подобное.²

Пройденный до сих пор путь можно обобщить так.

flowchart TB
    accTitle: Подсказка переходит от сохранённого места к отслеживанию, а затем к признакам
    accDescr: Если цели нет по сохранённому месту, пробуют доступные сведения отслеживания, а если и это не находит цель, пытаются искать по признакам.
    P["Проверить сохранённое место"] -->|"Не найдено"| I["Использовать сведения отслеживания"]
    I -->|"Недоступно или не найдено"| S["Искать кандидатов с подходящими признаками"]

Рис. 3: Общая схема обычного разрешения ссылки. Будут ли отслеживание и поиск вообще выполняться, зависит также от настроек и от того, как вызвана операция.

Совпавшая метка имени и похожие признаки — доказательства разной силы. Если несколько файлов имеют одно и то же имя или время создания, по одним лишь признакам нельзя доказать, какой из них настоящая цель. Это механизм не для того, чтобы сравнить всё содержимое и доказать тождество, а для того, чтобы заново найти потерянную цель.

К тому же поиск не продолжается безгранично. Приложение может указать флаги, подавляющие отслеживание или поиск, а административная политика может их ограничить. То, что файл открылся, само по себе не говорит, какая подсказка сработала.⁶

4. Копия с тем же содержимым — тот же файл?

Теперь скопируйте предложение.txt из «На_отправку» в «Распространение». Содержимое то же, но файлов стало два. Если отредактировать только один из них, второй сохранит своё содержимое.

Object ID тоже не дублируется обычным копированием как есть. Если бы в одном томе было два файла с одинаковым ID, метка имени уже не позволяла бы их различать. Microsoft поясняет, что копия не наследует тот же Object ID, что и оригинал.⁵

flowchart TB
    accTitle: Перемещение файла и его копирование означают разное с точки зрения идентичности
    accDescr: Перемещение сохраняет тот же файл, а обычное копирование создаёт отдельный файл с тем же содержимым, и исходный Object ID для отслеживания не дублируется как есть.
    O["Исходное предложение"] -->|"Обычное копирование"| C["Отдельный файл предложения"]
    O --> A["Исходная метка имени"]
    C --> B["Не наследует ту же метку имени"]

Рис. 4: Сделать содержимое одинаковым — не то же самое, что переместить сам исходный файл.

Вот ещё один случай, который многих удивляет. После того как исходный план перемещён в «На_отправку», что будет, если положить другой файл с тем же именем на освободившееся место Черновики\план.txt?

Как описано в разделе 1, обычно сначала проверяется сохранённое место. Если цель там найдена, до этапа поиска нового места дело может вообще не дойти. Иными словами, даже при наличии отслеживания нет гарантии, что будет выбран именно перемещённый вами исходный файл.¹

Ярлык — удобная точка входа, чтобы найти цель, которую можно открыть прямо сейчас. Это не механизм, который каждый раз доказывает, что перед вами тот же файл, что и раньше. Если держать это различие в голове, удобство и ограничения складываются в одно целое.

5. Проследите тот же файл на своём ПК

Если хотите попробовать, используйте текстовый файл, созданный в локальной папке для проверки, а не рабочий документ. Сначала создайте «Черновики» и «На_отправку» в пределах одного тома NTFS и сузьте условия, отказавшись от синхронизируемых папок и сетевых ресурсов.

Создайте файл в «Черновики», сделайте на него ярлык и убедитесь, что из него файл открывается. Затем переместите в «На_отправку» только сам файл и откройте ярлык. После этого переименуйте файл и попробуйте ещё раз. Каждый раз проверяйте, какой файл открылся.

Здесь важно, доберётся ли ярлык до нового места после того, как старое перестало быть пригодным. Если он не открылся, это не противоречит статье. Результат зависит от условий, при которых доступно отслеживание NTFS, от сохранившихся сведений, от настроек и так далее. Не ждите того же результата при переносе на USB-накопитель или на другой компьютер.⁵⁶

При написании статьи я проверил поведение и с помощью IShellLinkW::Resolve на локальном NTFS под Windows Server 2025 (сборка 26100). После перемещения и переименования возвращался новый путь, а в отдельной попытке, где на прежнее место был положен другой файл, возвращался старый путь. Это наблюдение за API в одной среде, а не испытание через интерфейс проводника Windows 11 и не проверка того, какой внутренний путь поиска использовался. Запись наблюдения тоже сохранена.

Если хотите выполнить сравнение с другим файлом на прежнем месте, начните заново с другим проверочным файлом. У ярлыка, который уже разрешался один раз, сведения о ссылке могут обновиться, поэтому тот же ярлык может уже не указывать на старое место.²

6. Для разработчиков: чтение пути и повторный поиск

Когда приложение работает с .lnk, тоже разделяйте чтение сохранённых сведений и поиск потерянной цели. Получение пути с помощью GetPath у IShellLink и попытка разрешить ссылку с помощью Resolve — не одна и та же операция.⁷

flowchart TB
    accTitle: Загрузить ярлык, а затем разрешить цель
    accDescr: Загрузить ссылку с помощью IPersistFile, попробовать разрешить её с помощью Resolve и получить разрешённый путь с помощью GetPath после подтверждения успеха.
    L["Загрузить ссылку"] --> R["Попробовать разрешить с помощью Resolve"]
    R -->|"Подтвердить успех"| G["Получить путь с помощью GetPath"]

Рис. 5: Прочитать строку прежнего места — не то же самое, что выполнить поиск нового.

В автоматической обработке интерфейс, показываемый при неудаче поиска, время поиска, использование отслеживания и обновление сведений о ссылке — тоже предметы проектирования. Например, SLR_NOSEARCH подавляет поиск по признакам, а SLR_NOTRACK — использование распределённого отслеживания ссылок. Флаги выбирают по цели, и не стоит считать успехом просто то, что открылось «что угодно».²

Отметим, что Object ID для отслеживания и файловый ID, получаемый из дескриптора файла, — не одно и то же. Сравнение файловых ID затрагивает и том. Не смешивайте их только потому, что оба называются ID; проверяйте, какой идентификатор из какого API имеется в виду. Переписывать Object ID вручную не нужно.⁸⁹

Кроме того, рассмотренный здесь .lnk — это файл оболочки. Он отличается от символьной ссылки, которая работает в рамках разрешения путей файловой системы, поэтому данное описание поиска нельзя переносить на неё как есть.¹⁰

Ярлык помнит не только «прежний адрес». Если по месту файл не находится, используются сведения отслеживания, а если и они непригодны — поиск по признакам. Поэтому он иногда следует за перемещением или переименованием. Но как только в дело входят копии с тем же содержимым или другой файл на прежнем месте, выбрать исходную цель удаётся не всегда.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 5, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

Похожие статьи

• Безопасное извлечение USB-накопителя и кэш записи

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Почему ярлык по-прежнему открывается после того, как исходный файл перемещён?

Потому что обычный ярлык .lnk умеет искать заново, используя доступные сведения отслеживания и признаки файла, когда сохранённый путь не приводит к цели. Это не просто строка пути. Однако в зависимости от файловой системы, настроек и условий поиска цель может так и не найтись.

Сравнивает ли ярлык содержимое файлов, чтобы найти исходный файл?

Описанное здесь разрешение ссылки использует путь, идентификатор отслеживания NTFS и такие сведения, как имя и время создания. Это не механизм, который доказывает, что файл является исходным, сравнивая содержимое. Даже если скопировать идентичное содержимое, эта копия — другой файл.

Если на прежнее место положить другой файл с тем же именем, откроется ли перемещённый исходный файл?

Откроется не обязательно исходный файл. Обычное разрешение ссылки сначала проверяет сохранённый путь, поэтому другой файл на прежнем месте может быть принят за цель. Не рассматривайте автоматическое отслеживание как гарантию того, что всегда будет выбран определённый файл.

Гарантировано ли отслеживание после переноса файла на USB-накопитель или другой компьютер?

Нет, это не гарантировано. Отслеживание NTFS и поиск по признакам — разные механизмы, и здесь играют роль файловая система назначения, сохранившиеся сведения отслеживания, службы и политики, а также состояние подключения. Если передать только ярлык, сам целевой файл вместе с ним не передаётся.

Ярлык и символьная ссылка — это одно и то же?

Нет, это разные вещи. Файл .lnk — это файл, который оболочка Windows читает, чтобы разрешить цель. Символьная ссылка — отдельный механизм, участвующий в разрешении путей файловой системы, и поведение поиска у файла .lnk на неё не переносится.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.