Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Общие вопросы по .NET и C# > Лимит на длину пути к файлу


Автор: infarch 7.2.2013, 10:22
Здравствуйте.

Хотелось бы узнать у тех кто в курсе: неужели до сих пор дотнет не умеет работать с путями длиннее 260 символов? Я когда то с этим столкнулся под дотнетом 2 еще. А на днях опять пришлось. И что? Уже есть дотнет 4 с половиной, космические корабли бороздят просторы Марса, а для длинных путей и дальше надо винапи юзать? Как то это дико...

Автор: Machaon 7.2.2013, 11:50
А что тебе мешает использовать системные каталоги ??

Код

Environment.GetFolderPath(Environment.SpecialFolder.каталог);


Ну а от него у тебя есть еще 260 символов.

Автор: infarch 7.2.2013, 14:24
И чем мне это поможет? По моему как раз наоборот - длина общего пути еще увеличится за счет пути к этой системной папке.

У меня есть структура папок в которой максимальный путь к конечному файлу может достигать и 1000 символов. И где бы она не лежала, хоть прямо на D:\, дотнет кидает ексепшены как только забирается поглубже.

Автор: wester 7.2.2013, 15:33
никак 
http://stackoverflow.com/questions/1394012/directoryinfo-fileinfo-and-very-long-path

Автор: infarch 7.2.2013, 16:25
Ну я так и сделал - через винапи работаю. Однако я просто не могу понять, почему? Почему этот пережиток до сих пор тянется из версии в версию?

Автор: Machaon 7.2.2013, 18:20
Сою ошибку понял.

А если не секрет зачем тебе использовать такие длинные пути ???

Если допустим в имени файла содержится какая то информация то ведь можно написать функцию которая будет преобразовывать её в более короткий вариант, а потом восстанавливать.

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

Автор: infarch 8.2.2013, 10:58
В общих чертах суть такая: есть SaaS система для строителей, облегчает работу с документацией. Там создается проект, юзеры закачивают файлы, заполняют формы и все такое. В конечном итоге получается дерево из разделов и данных. Сами понимаете, строительство дома от и до требует кучу документов, дерево выходит огромное. Пока это в вебе проблем нет. Но есть опция: Создать бекап. Вся структура пишется на диск как папки и файлы, потом переносится на DVD диск и идет заказчику по почте. Вот при постройке дерева и возникает проблема. Юзеры вводят огромные имена, а еще норовят вложить сотню папок одна в другую.

Автор: Machaon 9.2.2013, 15:57
мой совет: при бекапе переименовывай папки присваивая уникальный ID одновременно создавая базу ID с оригинальными названиями, 
при восстановлении подменяй ID из базы.

Автор: infarch 11.2.2013, 11:07
Да я бы с удовольствием... Только бекап этот для пользователей, из него ничего не восстанавливается. Просто файлы и папки. Так что надо его делать в точном соответствии той виртуальной структуре что в проекте создана. Иначе юзеры пугаются.

Автор: Machaon 13.2.2013, 00:30
ну вот тебе еще один извращённый вариант:

создаешь к примеру папку "Data"   в ней по выше мной написанному  методу создаешь структуру папок с ID именами

далее сопоставляя id c именами создаешь такую же  структуру ярлыков в корне dvd диска задаешь им имена и ссылки, а также по желанию иконки

в итоге получаешь:

БукваDVD:\Data\
БукваDVD:\ссылка на папку.lnk
БукваDVD:\ссылка на файлlnk
..... и тд.

Единственный минус при копировании пользователем с носителя куда либо данных ярлыки перестанут работать, но думаю можно написать батничек и уведомить пользователей при переносе бекапа кликнуть на него чтобы поправить ярлычки. (точно не знаю можно ли использовать относительные пути в винде никогда не сталкивался (вот тут говорят можно http://doitq.ru/2007/01/23/otnositelnyiy-put-v-yarlyike/) но если не получиться то как вариант)

В принципе я использовал бы такой вариант если не хотел бы гемороиться с API.

Автор: infarch 13.2.2013, 13:00
Увы, юзер должен получить структуру которая точно соответствует виртуальным папкам в его проекте. Папка Data это конечно хорошо, но все равно надо будет создать нечто вроде БукваDVD:\Folder1\Folder2\... А тут опять таки проблема длинного пути.


И еще... Юзеры работают под разными осями. Есть ли вариант кросплатформенных линков? 


Автор: iu1005 14.2.2013, 00:55
Я не знаю, как это переносится на DVD, но на дисках можно создавать "жесткие ссылки" (hard links). То есть пользователь может получать доступ к данным по полному пути, а вы - через ту папку, которую сами укажете. Ну а уж если длина достигает 1000 символов, то тут уже придется как минимум через 4 жестких ссылки (4 раза сокращать путь до 248 символов).

Автор: Machaon 14.2.2013, 02:49
Ну вот смотри используя к примеру 4-х значный id получаем (если использовать только числовой id:  260 / 5 = 52 ) делим на пять потому что незабываем про слеш и того получаем глубину адреса в 52 папки, то беж от корня у нас есть 52 папки.
при таком методе будет возможность использовать всего 9999 папок.

если использовать буквенно-цифровой id например (A314)  рассчитывая тем же методом получаем 21*999 = 20797 - максимальное число папок при глубине в 52 папки

полностью буквенный id  то 21 в 4-ой степени равно 194481 папке.

21 - количество букв латинского алфавита.

По поводу кросс платформы то можно вместо ссылок использовать HTML + проводник на JS и скрипт подмены ID на Имя и лазить как в обычном проводнике.

Возможно для тебя это будет самый "путёвый" вариант.

Автор: infarch 14.2.2013, 15:58
Цитата(iu1005 @  14.2.2013,  00:55 Найти цитируемый пост)
Я не знаю, как это переносится на DVD

А вот на двд это переносится как зип архив. Иными словами я делаю структуру папок, потом архивирую, архив на диск, диск пользователю. И ТЗ именно таково, что файлы и папки должны быть переданы один в один. Так что с айдишками ничего не выйдет. Клиент так хотят ) Собственно уже решили это организационными мерами. Бекапы редко заказывают, за них сервис деньги берет ) А перед генерацией подсчитываем путь. Если задлинный то просим юзера что нибудь переименовать или исключить из списка. Так что проблемы как таковой нет, только вопрос: начешуя этот лимит тянется с первых версий дотнета?

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)