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

382
Stephen Hanson

Под управлением 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/.

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

Щелкните правой кнопкой мыши> «Создать ярлык»

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

(т. е. ярлык на 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/

... НО -

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

Щелкните правой кнопкой мыши> «Создать ярлык»

метод.

Насколько я могу судить, при использовании 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,

ВОПРОС:

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

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

0
Я действительно не понимаю, в чем твоя проблема. Но вы можете прочитать [Имена файлов, путей и пространств имен] (https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247 (v = vs.85) .aspx), в которых есть особенности о том, как работать с более длинными путями. Кроме того, очевидным и простым решением было бы сократить пути или использовать программное обеспечение, способное работать с этими путями. Примером может быть не использование Explorer, а что-то вроде Total Commander. Кроме того, существует большая разница между использованием `mklink` с параметрами` / J` и `/ D`. Seth 7 лет назад 0
предел 260 MAX_PATH ** не ** относится к NTFS. Это просто предел старого Win32 API. Windows NT очень долго поддерживает путь длиной 32767 символов, и [Windows 10 также поддерживает более длинные пути] (http://stackoverflow.com/a/27694470/995714) phuclv 7 лет назад 1
@ Seth, разница здесь между сокращением 1000+ имен файлов по отдельности и просто сокращением более длинного каталога с помощью символической ссылки. Да, / J и / D разные, но ПРОБЛЕМА, которую я имею, остается неизменной, независимо от того, является ли это соединением или мягкой ссылкой. Я в курсе альтернативных файловых исследователей. Но мне нужна поддержка NATIVE Win32 API, потому что это среда, в которой большинство сторонних разработчиков разрабатывают свои приложения; методы переключения **, которые я использую ** для просмотра файлов, не гарантируют, что более 1000 файлов, которые у меня есть, останутся жизнеспособными для соответствующих приложений. Stephen Hanson 7 лет назад 0
@ LưuVĩnhPhúc Спасибо, что поправили меня по поводу Win32; Я обновил оригинальный пост, соответственно. Stephen Hanson 7 лет назад 0
@ LưuVĩnhPhúc Что касается совместимости Windows 10, поскольку она относится к более длинным именам файлов, хотя я уверен, что могу отключить параметр, который в настоящее время запрещает имена файлов длиной более 260 символов, я обеспокоен тем, что это приведет к нестабильности приложения. Есть ли способ так или иначе подтвердить, как манипулирование настройкой MAX_PATH повлияет на способность определенных приложений использовать затронутые файлы? Stephen Hanson 7 лет назад 0
нет никаких проблем, потому что только приложения, созданные для поддержки длинных имен файлов, будут иметь более длинный MAX_PATH, другие по-прежнему ограничены 260 символами, если они не используют путь в стиле NT https://blogs.msdn.microsoft.com/jeremykuhne/ 2016/07/30 / net-4-6-2-and-long-path-on-windows-10 / https://news.slashdot.org/story/16/05/31/0012222/microsoft-removes- 260-символьный путь длина предел-в-окон-10-Редстоун phuclv 7 лет назад 0
@ LưuVĩnhPhúc, следует отметить, что возникли некоторые сомнения в том, что Windows * на самом деле * проверяет манифест приложения, несмотря на то, что говорится в документации. Я не пытался проверить это сам. Harry Johnston 7 лет назад 0
Но на самом деле исправляя ваши пути, вам, вероятно, не пришлось бы сокращать имена тысяч файлов. По сути, насколько я понимаю, это ваш подход в любом случае. Просто не ясно, где вы столкнулись с проблемой. Как указывает исходная ссылка, вы можете просто использовать другой путь и дать ему шанс. Обычно, если вы делаете необычные вещи, такие как массовое превышение длины пути, вам понадобятся инструменты, которые поддерживают ваш случай или исправят ваши вещи, чтобы он соответствовал стандарту. Seth 7 лет назад 0
@ Поэтому решение, которое я ищу, состоит в том, чтобы структура каталогов выглядела идентично структуре с множеством вложенных каталогов, например, такой, которая создала бы файлы с путевыми именами длиной более 260 символов, если пользователь просто просматривает папки в Проводнике, или если приложение пытается обработать каждый ярлык / символическую ссылку / какую-то третью потенциальную альтернативу как фактическую папку, но с фактическими именами путей меньше, чем это. Ярлык = да, но с абсолютными путями, которые не копируются, Symlink (mklink) = относительные имена путей, которые копируют, но без более коротких путей. Stephen Hanson 7 лет назад 0

0 ответов на вопрос

Похожие вопросы