Длинные пути.

[Diff]

UC не умеет работать с файлами путь к которым длиннее чем 256 символов, хотя NTFS поддерживает пути до 32768 символов. Справедливости ради скажу, что знаю только один файлменеджер, это умеющий - mucommander.

[Max Diesel]

Полагаю в этом вопросе надо опираться на систему... если уж даже Проводник не умеет работать с именами длиннее 260-ти символов, то вероятно не стоит пытаться бежать впереди паровоза, ведь при беге впереди него нет права на спотыкание...

[Diff]

C одной стороны - оно так. А с другой - если считать Проводник за образец - то непонятно, зачем вообще браться за разработку файлменеджера.
Возможно, поможет это: http://msdn.microsoft.com/en-us/library/aa365247.aspx Ограничение в 256 символов введено микрософтом непонятно с какого перепою, но они же оставили лазейку с префиксом \\?\. Видимо, этот способ и использует джава на которой написан mucommander. Если его реализовать - у UC сразу появится область, в которой он будет превосходить всех конкурентов. Правда, неясно - как это скажется на производительности.

[Max Diesel]

Поставим вопрос под другим углом - Вам действительно надо иметь возможность работать с именами файлов длиннее 260-ти символов при факте что никакая другая программа на компьютере не сможет этими файлами воспользоваться? Если да, то поясните как же можно это использовать...
Эта "область превосходства над конкурентами" довольно бесполезная, подозреваю что ее обнаружили бы и, тем более, начали бы активно целенаправленно использовать не более чем 5-10 человек из всех пользователей программы.

[Diff]

Вам действительно надо иметь возможность работать с именами файлов длиннее 260-ти символов

Иногда -да. Последний раз - когда GetDataBack восстанавливая данные наглючила и насоздавала каталогов с неадекватной глубиной. Удалить их никто не мог, я напряг память и вспомнил, что mucommander написан на джаве, а джаве безразлична длина пути, поставил muc и удалил этот мусор. А если б не вспомнил - не знаю, что делал бы. Собственно, после этого и создал тему.

Эта "область превосходства над конкурентами" довольно бесполезная

Наберите в google "tc|far длина пути"

[Max Diesel]

Иногда -да. Последний раз - когда GetDataBack восстанавливая данные наглючила и насоздавала каталогов с неадекватной глубиной. Удалить их никто не мог, я напряг память и вспомнил, что mucommander написан на джаве, а джаве безразлична длина пути, поставил muc и удалил этот мусор. А если б не вспомнил - не знаю, что делал бы. Собственно, после этого и создал тему.

И часто ли появляется такая проблема? Один, два раза в жизни... рационально ли перестраивать ради этого программу под использование UNC-путей? (тем более при факте что даже Microsoft их не спешат использовать)... пока что я не вижу в этом смысла. Если бы все программы, включенные в в Windows, умели с такими путями корректно работать по умолчанию, то об этом стоило бы задуматься, но они не умеют... а чинить файловую систему на мой взгляд - задача не для файлового менеджера.

Наберите в google "tc|far длина пути"

Набрал и увидел несколько сообщений (не больше 10-ти), из которых можно сделать вывод что нескольким пользователям существование такой проблемы не нравится... Но что нужно набрать в строке поиска чтобы увидеть скольким пользователям до этого нет дела? То есть скольких устраивает длина пути в 260 знаков... я в математике не силен, но подозреваю что нужно использовать вычитание...

Полагаю не нужно бессмысленно спорить по этому вопросу, время его актуальности еще не пришло.

[MiceRus]

Поставим вопрос под другим углом - Вам действительно надо иметь возможность работать с именами файлов длиннее 260-ти символов при факте что никакая другая программа на компьютере не сможет этими файлами воспользоваться? Если да, то поясните как же можно это использовать...
Эта "область превосходства над конкурентами" довольно бесполезная, подозреваю что ее обнаружили бы и, тем более, начали бы активно целенаправленно использовать не более чем 5-10 человек из всех пользователей программы.

А вот и нет. Глубокое заблуждение.
Существует один старый косяк, при котором нельзя удалить файлы с диска. Даже сам WinEx не может их удалить.
Вобщем таких файлов полно бывает в каталоге винды и в каталогах Временных файлв интернета. Только использование UNC путей спасает народ. И при этом приходится юзать комстроку. Для современных "мышевозов" - это довольно нелегкий труд
Уж сколько на эту тему было написано...
В поисковиках искать не надо. Бо такие проблемы обсуждаеются в конфах FIDO и в курилках админов

[maXmo]

уж один раз в жизни мышевоз может в консоль зайти и там всё сделать.

[tl431]

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

[maXmo]

консоль дружит с subst'ом, проверено экспериментально.

[Qwertiy]

Полагаю в этом вопросе надо опираться на систему... если уж даже Проводник не умеет работать с именами длиннее 260-ти символов, то вероятно не стоит пытаться бежать впереди паровоза, ведь при беге впереди него нет права на спотыкание...

Есть DVD-диск. С него копируются каталоги (первого уровня) на жёсткий диск (третий уровень, но длина пути небольшая). В UC и TC периодически получается диалог Совпадение имён файлов, а Проводник копирует без проблем.

И часто ли появляется такая проблема?

Да, периодически.

PS: В чём смысл накладывания искусственных ограничений, если они не являются необходимыми?

[Max Diesel]

PS: В чём смысл накладывания искусственных ограничений, если они не являются необходимыми?

Про что вообще идет речь? Насколько мне известно, сейчас поддерживается взаимодействие с именами файлов длиннее чем 260 знаков...

[Qwertiy]

Про что вообще идет речь? Насколько мне известно, сейчас поддерживается взаимодействие с именами файлов длиннее чем 260 знаков...

Речи идёт о диалоге про совпадение имён файлов, который возникать не должен бы:

Есть DVD-диск. С него копируются каталоги (первого уровня) на жёсткий диск (третий уровень, но длина пути небольшая). В UC и TC периодически получается диалог Совпадение имён файлов, а Проводник копирует без проблем.

Возможно, причина в чём-то другом...

[Qwertiy]

Насколько мне известно, сейчас поддерживается взаимодействие с именами файлов длиннее чем 260 знаков...

Действительно, длинные пути поддерживаются, правда, с минимальными возможностями...

[Qwertiy]

В UC и TC периодически получается диалог Совпадение имён файлов, а Проводник копирует без проблем.

Выяснил, в чём причина. Действительно не в длине пути... Дело в dos-именах. Есть папка с файлами

Код: Выделить всё

Имя файла         DOS-имя
APB(1)~1-01.jpg   APB(1)~2.JPG
APB(1)~1.JPG      APB(1)~1.JPG

При копировании первым копируется файл APB(1)~1-01.jpg и его dos-именем оказывается APB(1)~1.JPG, после чего при копировании файла APB(1)~1.JPG возникает совпадение имён.

Кстати, похожая проблема уже упоминалась здесь.

PS: TC копирует правильно. Видимо с тех пор, как я видел в нём такое же сообщение как в UC, это уже исправили.