Нужна функциональность символической ссылки БЕЗ символического пути

Под управлением Windows 10 Pro.

Я пытаюсь обойти ограничение MAX_PATH в 260 символов, встроенное в Win32 API.

Я создал серию резервных копий, которые, как мы скажем, предназначены для резервного копирования "TRUNCATED" имен файлов.

Например, мы будем ссылаться на файл с полным именем файла:

D:/Folder1/Folder2/Folder3/Folder4/Folder5/Folder6/Folder7/Folder8/Folder9/file.txt

Для начала я теоретически сократил это имя файла, переместив файл в скрытую папку. Short_Name ближе к корню, так что файл теперь буквально существует как

D:/Short_Name/Folder9/file.txt

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

( такие как D:/Folder1/.../Folder9/ )

Я включил символическую ссылку с именем " Folder9 "

(достигается с помощью C:\Windows\system32> mklink /J ( или же /D ) "D:/Folder1/.../Folder9/" "D:/Short_Name/Folder9/" в командной строке)

D:/Folder1/Folder2/Folder3/Folder4/Folder5/Folder6/Folder7/Folder8/

такой, что ссылка выглядит

D:/Folder1/.../Folder9/

но указывает на D:/Short_Name/Folder9/,

СЕЙЧАС, очевидно, я мог бы вместо этого использовать обычный, заурядный

Нажмите правой кнопкой мыши & gt; "Создать ярлык"

но целевой путь ссылки такой символической ссылки будет абсолютным.

(т.е. ярлык на D: указывая на D:/Short_Name/Folder9/file.txt будет скопирован в C: но скопированный ярлык дублирует на C: все равно будет указывать на D:/Short_Name/Folder9/file.txt, )

Символические ссылки, с другой стороны ...

(то есть те, которые созданы с помощью C:\Windows\system32> mklink ... )

... скопировать относительные ссылки без проблем ...

(т.е. D:/Folder1/.../Folder9/ будет скопирован как C:/Folder1/.../Folder9/ )

... и цель ссылки будет копировать с

D:/Short_Name/Folder9/

C:/Short_Name/Folder9/

... НО -

Проблема ЗДЕСЬ заключается в том, что СЕЙЧАС ЛИТЕРАЛЬНЫЕ ИМЕНА ИСПОЛЬЗУЮТСЯ, как их более длинные, НЕРАЗРЕШЕННЫЕ версии, что НЕ произошло бы при использовании

Нажмите правой кнопкой мыши & gt; "Создать ярлык"

метод.

Насколько я могу сказать, при использовании mklink чтобы создать символическую ссылку на каталог (НЕ файл - я не знаю, работает ли он по-разному для файлов), системное имя файла LITERAL любого файла, размещенного в каталоге, например: D:/Short_Name/Folder9/ кажется, только когда-либо, mklink символический путь, то есть путь

D:/Folder1/Folder2/Folder3/Folder4/Folder5/Folder6/Folder7/Folder8/Folder9/file.txt

даже если фактическое местоположение файла только

D:/Short_Name/Folder9/file.txt,

ВОПРОС:

Есть ли ЛЮБОЙ способ создания символической ссылки, которая будет функционировать как стандартная папка, но которая ТАКЖЕ будет поддерживать ОТНОСИТЕЛЬНУЮ, ЛИТЕРАЛЬНУЮ, УСТАНОВЛЕННУЮ версию файла при копировании на новый диск?

Пожалуйста и спасибо.

— Stephen Hanson
источник

Я действительно не понимаю, в чем твоя проблема. Но вы можете прочитать Именование файлов, путей и пространств имен который имеет особенности о том, как работать с более длинными путями. Кроме того, очевидным и простым решением будет сокращение путей или использование программного обеспечения, способного работать с этими путями. Примером может быть не использование Explorer, а что-то вроде Total Commander. Кроме того, существует большая разница между использованием mklink с вариантами /J а также /D,

— Seth

предел 260 MAX_PATH равен не связанные с NTFS. Это просто предел старого Win32 API. Windows NT поддерживает путь 32767 символов в течение очень долгого времени, и Windows 10 также поддерживает более длинные пути

— phuclv

@ Seth, разница здесь между сокращением 1000+ имен файлов по отдельности и просто сокращением более длинного каталога с помощью символической ссылки. Да, / J и / D разные, но ПРОБЛЕМА, которую я имею, остается неизменной, независимо от того, является ли это переходом или мягкой ссылкой. Я в курсе альтернативных файловых исследователей. Но мне нужна поддержка NATIVE Win32 API, потому что это среда, в которой большинство сторонних разработчиков разрабатывают свои приложения; методы переключения я использование для просмотра файлов не гарантирует, что более 1000 файлов, которые у меня есть, останутся жизнеспособными для соответствующих приложений.

— Stephen Hanson

@ LưuVĩnhPhúc Спасибо, что поправили меня по поводу Win32; Я обновил оригинальный пост, соответственно.

— Stephen Hanson

@ LưuVĩnhPhúc Что касается совместимости Windows 10, поскольку она относится к более длинным именам файлов, хотя я уверен, что могу отключить параметр, который в настоящее время запрещает имена файлов длиной более 260 символов, я обеспокоен тем, что это приведет к нестабильности приложения. Есть ли способ так или иначе подтвердить, как манипулирование настройкой MAX_PATH повлияет на способность определенных приложений использовать затронутые файлы?

— Stephen Hanson