Вот странное поведение, с которым я столкнулся при работе с mklink
который поставляется в Windows начиная с Vista. Я подозреваю, что может быть дефект в mklink
или даже так глубоко, как драйвер файловой системы NTFS, но поведение может использовать некоторые объяснения. Такое поведение встречалось в Windows 7 и 10 соответственно.
Предположим, у нас есть каталог на томе NTFS (НЕ пытайтесь делать это ни на чем, кроме тома, который вы создаете для этой единственной цели!) и файл с именем bar.txt
внутри него.
md F:\1
echo foo > F:\1\bar.txt
Теперь введите следующую команду (через привилегированное приглашение):
mklink F:\1:bar F:\1\bar.txt
... который должен дать вам:
symbolic link created for F:\1:bar <<===>> F:\1\bar.txt
Не волнуйся, я знаю, что это глупо. Но это был результат теста, может ли альтернативный поток данных (ADS) стать точкой повторной обработки. Я считал, что это невозможно, потому что альтернативный поток данных имеет только имя, размер и - ну, - данные внутри него. В отличие от файла или каталога, он не имеет атрибутов файла или собственных меток времени, и поэтому не будет никакого атрибута для обозначения ADS в качестве точки повторной обработки (что иначе происходит через атрибуты файла). Или иначе: точки повторной обработки могут ссылаться только на записи каталога (через $Extend\$Reparse
), тогда как ADS привязаны к записям каталога.
Результат приведенной выше команды таков:
F:\>dir /r
Volume in drive F is TEST
Volume Serial Number is 24F3-8A7D
Directory of F:\
2018-04-03 20:47 <SYMLINKD> 1 [F:\1\bar.txt]
0 1:bar:$DATA
0 File(s) 0 bytes
1 Dir(s) 4,244,283,392 bytes free
Неудивительно, что попытка перейти в этот каталог не работает и приводит к неверному The directory name is invalid.
Аналогично, попытка удалить точку повторной обработки с помощью junction -d
(из пакета Sysinternals) или с помощью fsutil reparsepoint delete
завершается с той же ошибкой. Только проверка данных точки повторной обработки дает мне возможность цепляться за:
F:\>fsutil reparsepoint query F:\1
Reparse Tag Value : 0xa000000c
Tag value: Microsoft
Tag value: Name Surrogate
Tag value: Symbolic Link
Reparse Data Length: 0x00000044
Reparse Data:
0000: 18 00 20 00 00 00 18 00 00 00 00 00 46 00 3a 00 .. .........F.:.
0010: 5c 00 31 00 5c 00 62 00 61 00 72 00 2e 00 74 00 \.1.\.b.a.r...t.
0020: 78 00 74 00 5c 00 3f 00 3f 00 5c 00 46 00 3a 00 x.t.\.?.?.\.F.:.
0030: 5c 00 31 00 5c 00 62 00 61 00 72 00 2e 00 74 00 \.1.\.b.a.r...t.
0040: 78 00 74 00 x.t.
Теперь мой вопрос: что здесь произошло, и как мне снова избавиться от такой точки повторной обработки с помощью встроенных инструментов Windows (или, в случае неудачи, внешних)? Бонусные баллы за возможность ответить на то, что случилось с файлом в папке 1
и раскрыть вашу методологию.
Моя рабочая теория до сих пор выглядит следующим образом:
mklink
создает "файл"F:\1:bar
и успешно (предположительно, черезCreateFile()
).mklink
устанавливаетREPARSE_DATA_BUFFER
для созданного "файла", который не может работать как ADS в каталоге. Поэтому внутренне происходит то, что драйвер файловой системы устанавливает буфер повторных данных в каталоге.
Результат - это то, что мы видим. Что меня беспокоит, так это то, что обычно вы не можете получить указатель на каталог без указания определенного флага. Таким образом, мы не только заставили mklink
создать символическую ссылку в каталоге на файл, но и избежали необходимости указывать FILE_FLAG_BACKUP_SEMANTICS
.
Документация FILE_FLAG_BACKUP_SEMANTICS
в CreateFile
гласит:
Вы должны установить этот флаг, чтобы получить указатель на каталог. Дескриптор каталога может быть передан некоторым функциям вместо дескриптора файла. Для получения дополнительной информации см. Раздел «Примечания».
Для воспроизведения я настоятельно советую вам не пытаться сделать это на существующем диске NTFS, а вместо этого создать новый, используя драйвер диска ImDisk RAM и соответствующий инструмент командной строки imdisk
(через привилегированное приглашение):
imdisk -a -t vm -p "/fs:ntfs /q /y /v:TEST" -s 4G -m F:
(Измените параметры по своему усмотрению. -m
обозначает букву диска и -s
размер ОЗУ.)