Вынужден сам писать регламент на ресурсы своего отдела.
Столкнулся с тем, что IT иногда после обоснованной ротации вверенных им в обслуживание ресурсов по разному «клеят» мои корневые папки (лог.диски). Я всех своих застроил, объявил ограничение в 200знаков, IT дал в 240 (с технологическим запасом). Для подсчета кол-ва символов нашел шароварную утилиту, которая из буфера обмена всплывающим окном показывает результат.
Как вы организовали такие ограничения? Нашли ли способ принудельно ограничивать длину полного имени файла?
Проблема стандартная. Особые проблемы возникают при организации резервного копирования информации (все сторонние утилиты резервного окпирования пугаются длинных полных имен файлов). Спасает только встроенная в Windows 2003 Server утилита резервного копирования (Backup). Пока для меня средство борьбы с длинными именами - это структуризация информации и жесткие организационные меры.
Ерунду написали. Системы резервного копирования прекрасно обрабатывают длинные имена.
Приведите примеры таких систем - протестировать хочется.
Цена: 390 руб.
Syncsort Backup Express. У меня на сайте можете прочитать подробнее. Официальный сайт syncsort.com.
Спасибо, буду пробовать. В описании не встретил про обработку длинных (>255 символов) имен файлов.
Артур, это даже не выносится на обсуждение. Если полный путь файла превышает 255 символов это совершенно не создаёт проблем.
Хотя если Вы имеете в виду длину имени САМИХ ФАЙЛОВ то тут могут быть скрытые проблемы. Я не уверен, но думаю что в спецификации NTFS 255 символов это предельная длина имени файла.
Вобщем пробовать надо.
оперционная\файловая системы какие?
Windows 2003 Server, NTFS
просто ищу удобный способ принудительного ограничения имен до 200 знаков из 255 возможных для пользователей.
Цена: 750 руб.
А в связи с чем такие приседания? В чём состоит исходная проблема?
Мой ресурс технический - конструкторская документация, переписка по техническим заданиям, справочные материалы и прочее. Вообщем интеллектуальная собственность предприятия. требования к сохранности очень высокие. Не смотря на имеющийся регламент IT, я вынужден проводить периодически полный back up в виде эл.копии, так и на твердом носителе. За 5 лет это спасало меня не раз. Проанализировав причины, вышел на лимит винды - 255 знаков. Так как IT внутри массива данных время от времени перемещает папки из-за длинных имен уже имеющихся ресурсов происходит конфликт внутри винды. Файлы не читаются, не копируются, не удаляются. А при случае когда проводится восстановление после сбоя - файлы оказавшиеся за пределами 255 занков восстанавливаются как файлы нулевой длины.
Я начал писать регламент, ограничив для своего отдела длины полного имени до 200 знаков. IT поставил предел 240 знаков,оставив 15 знаков на форс-мажор. Поэтому хотел бы узнать, кто с подобной проблемой сталкивался и как ее решил в части принудительного огрнаичения длины полных имен.
То есть основная проблема - в бэкапах, как я понял? Может быть попробовать другой софт для резервного копирования?
Для Вашей задачи могу предложить Вам интересное решение для ГАРАНТИРОВАННОЙ сохранности данных. - CAStor. Настройка минимальная, в винде ничего менять не надо, агента только доставить.
Ну и с системой резервного копирования которую я внедряю никогда ни у кого таких проблем не наблюдалось.
Я использую bacula для архивации в том числе и виндовых машин. Вроде длинные пути нормально архивируются и восстанаыливаются.
Цена договорная
В Bacula проблемма с длинными именами файлов не решена. Тут дело даже не в Bacula, а в том, что сама винда с FAT/NTFS не может работать с такими файлами. Ни копировать, ни удалять. Проблемму можно решить только уменьшением длины пути где-то на середине. Т.е. сокращать длину пути к файлу.
Сталкивался, только при копировании, ntbuckup прекрасно справляется. И вот однажды мы купили в сервер новый диск и не смогли на него скопировать длинное-длинное-длинное-длинное-длинное имя файла и пары папки к ней, поскольку была сохранена страница целиком в IE без изменения заголовка, копироваться отказалась. Своих коллег предупредил - "Если будете сохранять с такими именами, файлы будут пропадать, претензии билли". Для Вас могу сделать программку, будет следить за указанной директорией, при помещении туда длинных файлов будет его переименовывать.
Лев,
у меня имена файлов содержат децимальные номера чертежей и документов, на этом держится мой документооборот. В PDM системах в основном база так и строится как ты говоришь, все что берется на хранение система переименовывает в некий номер по порядку и произвольный номер. Но на PDM денег не дают, поэтому учет ведем по устоявшейся у нас упрощенной системе.
Сейчас могу лишь только одной прогой считать символы скопрированные в буфер. А вот найти бы способ принудительного запрета ввода имени более n-символов. Такую бы приблудку написать.....
Вот очень удобная вещь. Не будем забывать о бесплатном ПО, пользуюсь для ведения документа оборота по строительству. Изначально бесплатна, платно только в случае если будет принято решение о расширении функционала до платной версии, но могу уверить и бесплатно работает изумительно. http://www.nanocad.ru/products/detail.php?ID=27915 Ознакомиться рекомендую также с соседними проектами.
Для моих задач не годится. у меня машиностроение - металка, электроника...большой ресурс конструкторский toolbox и куча прочей учетной хрени.
тут на форуме предложили - Open Source ECM Alfresco - система электронного документооборота с открытым кодом
описалово тут:
http://www.myalfresco.blogspot.com/
как появится время, подымем сервак и будем тестить. думаю не раньше июня.
но это у кардинальное решение моей проблемы, но увы не скорое. А пока ищу то что писал выше. Любой IT будет рад такой проге чтобы застроить пользователей.
Цена: 9 990 руб.
Ладно, принялся за задачу, вот в первом приближении:
Разрабатываем технологию, и методику решения.
Задачи:
Запрет создания пользователям файлов с именами длиннее установленного.
Средства:
Delphi, WinApi.
Результаты:
Сервис установленный у пользователей, Конфигуратор установленный у администратора.
Подробные варианты решения:
1) Задача сервиса - следить за дисками, при создании файла проверить его длину, если больше допустимого выдать сообщение пользователю " имеет длину больше допустимой, для корректной работы переименуйте его либо переместите ближе к корню диска." Тут возникают проблемы:
a) Создание-копирование служебными программами (например IExplore сохраняет довольно длинные пути файлов в кеше что-то вроде C:\Documents and Settings\UserNAME\Local Settings\Temporary Internet Files\Content.IE5\GHIJ2L45), решить можно настройкой исключений (для процессов и для директорий). Очевидно, лучше будет следить не за всем диском, а за списком директорий коим «должно быть короткоименными».
b) В данном варианте мы получим системное сообщение постфактум, то есть информацию о создании такого файла мы получим после фактического создания файла, однако имея его путь ничто не мешает нам его удалить или переместить в «карантин».
c) Слежение за диском создает небольшое падение производительности дисковой системы, а проверка допустимости имен помимо этого требует процессорного времени, однако это небольшая величина и ею можно пренебречь.
2) Задача сервиса - альтернативное решение, можно не полагаться на сообщения Windows, мы можем внедрить свою dll в explorer (возможно внедрение и в другие процессы) и переопределить winapi вызовы функций, таким образом пользователь создавая или копируя файл выполнит переопределенную функцию создания файла в которой мы проверим путь и если он не понравится нам не будем его создавать. Тут возникают проблемы:
a) Некоторые антивирусы и Firewalls , будут определять внедрение dll и сообщать о нашем сервисе как о вирусе.
b) Технически более сложное решение потребуется отладка и опытная эксплуатация.
3) Модуль администрирования имеет следующие задачи:
a) собирание логов от сервисов рабочих станций - «кто-когда-чего не там создать пытался, у кого сервис не запустился, и т.д.»
b) Назначение директорий исключений и/или целевых директорий для отслеживания длинны имен файлов, назначение исключений-включений процессов, другие настройки сервиса.
c) Сбор файлов теневого копирования из «карантина»
Таким образом вот первое приближение решения данной задачи, программный комплекс находится на стыке прикладного и системного программирования, прикладной частью является сетевой обмен и конфигурирования станций, сам сервис относится к системному программированию. Стоимость данного проекта при текущем Т.З. 150$, время реализации 5-6 дней. Тупая утилита молча удаляющая файлы с неподходящим именем-путем 80$ 2-3 дня. Возможно изменение проекта, В дальнейшем при большом объеме данных могу прикрутить mySql для хранения данных, возможна доработка в сторону предупреждения администратора о «неправильном копировании файлов» по почте например. Могу выслать пример внедрения dll, готов к сотрудничеству.