У сисадминов есть головняк с ламерами, которые дают своим файлам нереально (смысл противоположный от unreal'но ) длинные названия. Потом с этими файлами куча проблем. Ясно, что ламеры должны знать, кто они такие, но, блин, достало учить их. В общем, имеет смысл при переименовании файла вводить ограничение (опциональное) на количество символов.
Есть ещё большое подозрение, что проблемы с файлами возникают при переносе в папку, полный путь к которой более длинный: количество символов в описании полного пути к файлу увеличивается, и с файлом начинаются проблемы. Контрольной проверки этого не делал, но если это так, то, наверное, стоит проверять это и при выполнении операций копирования/переноса.
Наверное, также, стоит есть учесть возможную разницу в платформенных требованиях к длине пути/имени файла в XP, Viste, 7-ке, и на всех других платформах, с которыми UC компатибелен.
P.S. в поиске с ходу ничего похожего не нашел, но если баян - ткните носом, куда писать.
Ограничение на кол-во символов при переименовании
Модератор: motyara
-
- Сообщения: 6
- Зарегистрирован: Пт мар 18, 2011 2:09 pm
Ограничение на кол-во символов при переименовании
С респектом,
Сергей
Сергей
-
- Охотник за багами
- Сообщения: 1199
- Зарегистрирован: Вс янв 31, 2010 12:12 am
Я против всего предложенного. Есть файловая система и то, что для неё является корректными именами. И если Microsoft напихала кучу собственных, к тому же необоснованных, ограничений в ОС (Проводник, диалоги и т. д.), то надо писать им, чтобы они их убрали (правда, это бесполезно).
Хотя, если делать опционально, то не думаю, что оно сильно помешает...
Хотя, если делать опционально, то не думаю, что оно сильно помешает...
-
- Сообщения: 6
- Зарегистрирован: Пт мар 18, 2011 2:09 pm
Re: Ограничение на кол-во символов при переименовании
На сколько я знаю, такой фичи больше нигде нет. И её реализация (думаю, не такая уж и сложная) только прибавит популярности UC.
Что касается Мелкомягкой вольной трактовки стандартов - если и исправят, то только в какой-нить новой винде: вряд ли это по силам рядовому обновлению. И будем опять несколько лет думать, переходить ли на новую винду из-за этой да ещё пары каких-нить невостребованных фич (облачные вычисления, очередной "революционный" интерфейс и т.п.)...
Думаю, файловый менеджер - это как раз тот, кто и может сейчас позаботиться о пользователе. Жаль, что популярность файловых менеджеров падает - можно даже задуматься о написании какой-то фичи для проводника, если это возможно.
Что касается Мелкомягкой вольной трактовки стандартов - если и исправят, то только в какой-нить новой винде: вряд ли это по силам рядовому обновлению. И будем опять несколько лет думать, переходить ли на новую винду из-за этой да ещё пары каких-нить невостребованных фич (облачные вычисления, очередной "революционный" интерфейс и т.п.)...
Думаю, файловый менеджер - это как раз тот, кто и может сейчас позаботиться о пользователе. Жаль, что популярность файловых менеджеров падает - можно даже задуматься о написании какой-то фичи для проводника, если это возможно.
С респектом,
Сергей
Сергей
-
- Охотник за багами
- Сообщения: 1199
- Зарегистрирован: Вс янв 31, 2010 12:12 am
Не очень-то я уверен в её полезности...s-fad писал(а):На сколько я знаю, такой фичи больше нигде нет. И её реализация (думаю, не такая уж и сложная) только прибавит популярности UC.
Поэтому и написал, что опция мешать не будет.s-fad писал(а):Думаю, файловый менеджер - это как раз тот, кто и может сейчас позаботиться о пользователе.
От них редко чего хорошего дождёшьсяs-fad писал(а):Что касается Мелкомягкой вольной трактовки стандартов - если и исправят, то только в какой-нить новой винде: вряд ли это по силам рядовому обновлению. И будем опять несколько лет думать, переходить ли на новую винду из-за этой да ещё пары каких-нить невостребованных фич (облачные вычисления, очередной "революционный" интерфейс и т.п.)...
Откуда информация?s-fad писал(а):Жаль, что популярность файловых менеджеров падает - можно даже задуматься о написании какой-то фичи для проводника, если это возможно.
Для Проводника есть QT Tab Bar - добавляет вкладки и ещё что-то... Когда-то пользовался даже.
-
- Сообщения: 4
- Зарегистрирован: Пт фев 28, 2014 11:31 am
Re: Ограничение на кол-во символов при переименовании
Ограничивать не считаю нужным, но предупреждать пользователя при ЛЮБЫХ действиях с длинными путями/именами считаю нужной функцией.
Также из этого вытекает, что при копировании/перемещении структур, не хватает параметров для обработки путей с длинными путями. Иначе, найдя такой путь, операция прервётся и будет ждать ответа.
П.с. Приходится копировать по-сети различную информацию и очень часто бывает, что UC подводит, пропуская файлы по длинным путям. TC в этом случае спрашивает, что делать.
Также из этого вытекает, что при копировании/перемещении структур, не хватает параметров для обработки путей с длинными путями. Иначе, найдя такой путь, операция прервётся и будет ждать ответа.
П.с. Приходится копировать по-сети различную информацию и очень часто бывает, что UC подводит, пропуская файлы по длинным путям. TC в этом случае спрашивает, что делать.
-
- Автор программы
- Сообщения: 3432
- Зарегистрирован: Пт окт 12, 2007 3:26 pm
Диалог с вопросом о том, что следует делать с экстремальными именами файлов, пока в планы не входит (возможно позже будет добавлен), однако пропущенных файлов с длинными путями (как сетевых, так и локальных) со следующего билда предположительно быть не должно.SibD писал(а):Ограничивать не считаю нужным, но предупреждать пользователя при ЛЮБЫХ действиях с длинными путями/именами считаю нужной функцией.
Также из этого вытекает, что при копировании/перемещении структур, не хватает параметров для обработки путей с длинными путями. Иначе, найдя такой путь, операция прервётся и будет ждать ответа.
П.с. Приходится копировать по-сети различную информацию и очень часто бывает, что UC подводит, пропуская файлы по длинным путям. TC в этом случае спрашивает, что делать.
-
- Сообщения: 405
- Зарегистрирован: Чт ноя 08, 2007 9:29 am
- Откуда: Москва
Re: Ограничение на кол-во символов при переименовании
Интересно было бы посмотреть на пример таких имен файлов, что мешают жить...s-fad писал(а):У сисадминов есть головняк с ламерами, которые дают своим файлам нереально (смысл противоположный от unreal'но ) длинные названия. Потом с этими файлами куча проблем. Ясно, что ламеры должны знать, кто они такие, но, блин, достало учить их. В общем, имеет смысл при переименовании файла вводить ограничение (опциональное) на количество символов.
Есть ещё большое подозрение, что проблемы с файлами возникают при переносе в папку, полный путь к которой более длинный: количество символов в описании полного пути к файлу увеличивается, и с файлом начинаются проблемы. Контрольной проверки этого не делал, но если это так, то, наверное, стоит проверять это и при выполнении операций копирования/переноса.
Наверное, также, стоит есть учесть возможную разницу в платформенных требованиях к длине пути/имени файла в XP, Viste, 7-ке, и на всех других платформах, с которыми UC компатибелен.
P.S. в поиске с ходу ничего похожего не нашел, но если баян - ткните носом, куда писать.
А у вас ламеры работают с UC?))
С уважением, Андрей.