Программа расчета и проверки контрольных характеристик файлов.

[cfl 0]

На форумах много написано о PDM системах. У нас на предприятии бизнес система отделена от документации. Данные в нее о структуре изделия заносит - одно подразделение, ценники на покупные и материалы материалы - вводит отдел снабжения, нормы затрат на детали и сборки - технологи, покупные в базу заводят на основании уведомлений от конструктора (основа наша ВП) и т.д. Данная система написана своими программистами в ней много примочек для анализа себестоимости изделий (для экономистов), и видно все это связано с бухгалтерией.

А мы - конструктора просто разрабатываем документацию и сдаем ее в ОТД, который ведет ее учет, хранит, размножает и проводит изменения в подразделениях. Мной написана программа CFL и мы ее используем при передачи электронной документации. На бумаге только удостоверяющие листы и извещения, хотя извещения тоже можно сдавать в электроном виде - берем бланк извещения А5 на кальке (для подписей), а в нём пишем "Содержание извещения в приложении - файл такой-то, КХФ такая-та".

Вроде при работе с ней нас все устраивает.

Хотелось бы, чтобы вы её потестировали. А также рассказали, что и как вы используете для такого простого электронного документооборота.

Сайт программы www.controlfilelist.com

[GOLF_stream 293]

Посмотрел сайт.

Так и не понял в чём выгода. Зато понял что нужно очень много чего делать вручную. И опять же не понятно для чего.

Удивила фраза: "Что самое важное в документообороте - хранение документов." Извините, но это абсурд. Данные хранятся на жестком диске или на любом другом носителе без всякой системы документооборота. Они просто хранятся. Для хранения не нужно ничего, кроме свободного пространства.

В общем, скачивать нечто непонятное не буду.

[cfl 0]

Вопрос в том - хранится тот файл или не тот. Только имея список контрольных характеристик файлов (например на все изделие) пакета документации можно гарантировать целостность данных. Файлы можно запортить запросто: вирус, сам ткнул пальцем в F4 FARа. При сдаче в ОТД бывают ошибки которые ОТД отслеживает: применяемость, фамилии в основной надписи и в УД, возможность делать копии после выдачи на плоттер. Приходится заменять некоторые файлы, а в ОТД пока не приняли извещение - бывают и путаются в файлах (если имена файлов одинаковые).

[cfl 0]

Версия 1.5 с проверкой вложеных CFL файлов. Полноценный демо режим.

У нас в ОТД первый случай - запорчен файл. Два байта в файле обнулены, причина не установлена.

cfl.zip

[oracloid 0]

cfl, т.е. Ваша программа просто считает контрольные суммы и проверяет, соответствуют ли они имеющимся файлам? такие вещи обычно применяются для валидации закачек, - например, чтобы проверить не битый ли образ дистрибутива перед нарезкой на болванку. подобный функционал реализуется на любом языке программирования (включая batch скрипты) минут за 20 при наличии библиотеки или внешней утилиты для подсчета хэшей. впрочем, проще воспользоваться гуглом и найти что-нибудь вроде этого - <noindex>http://md5deep.sourceforge.net/</noindex>

[cfl 0]

Да, программа просто проверяет контрольные характеристики файлов начиная с текущего каталога.

У нас в КБ, например всего примерно 5000 документов (zip файлов) в электронном виде, которые размещены по изделиям в 20 головных папках(т.е. 20 cfl файлов).

Данная программа позволяет проверять целостность этих документов. А как вы проверяете целостность тысячи файлов - CRC32 в zip архивах, в файловой системе и в сетевом обмене явно не достаточна для гарантии неизменности файлов.

CFL файл представляет собой ведомость электронных документов на изделие в текстовом виде (UTF-8 - имена файлов пишите на каком хотите языке). В этом файле можно прописать комментарии к файлам, сделать шапку ведомости (я такой программы не нашел).

У меня дома стоит сетевой внешний диск с Linux - в котором имена файлов с прописными и строчными буквами различаются, т.е. Jar.jar и jar.jar в одном каталоге - это разные файлы. А какую операционную систему вы будете использовать для хранения файлов? Покупаем Windows. У меня друг работает в Oracle, так он что-то все c Linux. Программа написана на Java - одна программа для Windows и Linux.

P.S. Я изучал Java на этой программе (что в самый раз), времени ушло уйма. Написал ее потому, что в инете такой нет.

Изменено 6 августа 2012 пользователем cfl

[oracloid 0]

вами создана программа для подсчета контрольных сумм файлов по списку или в указанной директории. этот же функционал наверняка присутствует и в вашей системе PDM, но либо эта система внедрена криво, либо местные программисты создали очередное кривое поделие.

программа по ссылке умеет ровно все то же самое плюс еще несколько удобных фич. - это к вопросу о том, что " в инете такой нет". есть. просто искали плохо.

для хранения документов применяют системы типа того же Oracle Oracle WebCenter Content (бывший UCM), например. в большинстве PDM систем также тем или иным образом реализовано хранение данных. в системах электронного документооборота, где количество записей превышает сотни тысяч и миллионы, размеры БД могут достигать нескольких Тб, а в отдельных случаях гораздо больше. аппаратно в таких случаях система хранения данных (СХД) часто выполняется отдельно, т.е. используются дисковые массивы и SAN. в интегрированных готовых комплексах (типа Exadata и прочие) для хранения самих файлов БД используются отдельные storage cell - выделенные именно для файлохранения диски, способные обрабатывать низкоуровневые операции с БД в параллельной конфигурации. ОС на продакшн-серверах обычно, да, linux хотя изредка встречаются и windows. Опять же встает вопрос архивирование и бэкапа. для оперативного архивирования можно использовать компрессию и партиционирование данных, когда более старые и реже используемые данные сжимаются и/или помещаются на более дешевые-экономные машины. ленточный бэкап применяется для долгосрочного архивирования и регулярных бэкапов больших объемов данных, аппаратно это ввыглядит например как ленточная библиотека на несколько десятков или сотен кассет.

из близких областей можно вспомнить о системах версификации, которые обычно применяются в командной разработке программного кода. с их помощью возможна организация хранения структурированных (текстовых) данных "с историей", вплоть до отката на определенную версию указанного файла.

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

[cfl 0]

Убил 2 часа тестируя прогу по ссылке. Да... сразу пример не посмотрел - думал по хелпу проги (md5deep.exe -h) разберусь - как же. Я впервые вижу прогу которой при проверке нужно передовать полный список файлов которые и так есть в тестируемом файле - маразм.

hashdeep -c md5 -l help.txt hashdeep64.exe > known.txt получаем файл с характеристиками двух файлов

hashdeep -c md5 -l -a -k known.txt help.txt hashdeep64.exe а тут проверяем - передаем сам файл и обязательно зачем-то повторяем список файлов

Коментарии к файлам записать в текстовывй файл нельзя. Зачем-то в начале пишит размер файла, а так как файлы разных размеров, то в текстовом виде все сдвинуто - карявый список.

В прикрепленном файле - а как у меня в файле.

А по хранению документации у нас все просто, без баз данных. Для не больших групп разработчиков - хоть какой-то порядок в файлах-документах. А администрировать отдельную БД под это, тоже не просто. У нас может когда-нибудь программисты, и прицепят в базе предприятия к сборкам и чертежам раздел документации. Но тут ещё и с цифровыми подписями завязываться придется. Так что пока - чем проще, тем лучше.

[oracloid 0]

собственно без разницы, зачем вы свою систему хранения данных строите с помощью мусора и веточек и изобретаете неудобные велосипеды.

вотетовот то, что вы делаете - это онанизмом на производстве называется.

[cfl 0]

Не уж-то у всех разработчиков КД, ТД, строительной документации для хранения документации разработанной в САПР используются базы данных?

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

Вот в былые времена, у нас в КБ плоттера не было (и сейчас нам он не нужен), а в другом КБ перьевой-глючный, а документации разрабатывали много - вот и стали, еще с 1997 года документацию в электронном виде в ОТД сдавать.

С такой программой, это самый простой способ работать с электронными документами.

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

P.S. Ну, и если вы у себя на компе, не можете разобраться со своими же файлами, то вам и ни какая база данных не поможет.

[oracloid 0]

cfl, мне сложно сказать. в моем ведомстве не только и не столько мелкие системки для собственных нужд вроде сервера сайта компании. хотя и в этом случае использовались ssh-туннели для безопасной передачи трафика в/от внешнего выделенного сервера. образ виртуальной машины (а точнее - OpenVZ container со всей требухой типа операционки с настройками, приложений, сервера базы данных на PostgreSQL и содержимого памяти) ежедневно архивируется на магнитную ленту по стандартной схеме в несколько недель, бОльшая часть данных архивируется инкрементально.

то же самое - с мелочами вроде CRM и критическими для бизнеса данными и инструментами (большей частью - полностью виртуализированные макеты IT инфраструктуры предприятия, например, несколько серверов БД, работающих в кластере плюс одна машинка под менеджмента и управления этим хозяйством.

и это я еще отказался от использования Oracle VM, используя преднастроенный дистрибутив debian - proxmox. в противном случае, мне лучше было подключить еще один небольшой сервер для БД и инструментов менеджмента самой среды виртуализации.

Т.е. в принципе я особо не задумываюсь о проверке целостности данных, - это происходит на слишком низком уровне в автоматическом режиме. Для кэширования статического контента, например, на внешний прокси-сервер используется простенький rsync, который гарантирует защищенный канал связи с контролем целостности. Что-то не отправилось - nagios или какой-нибудь zabbix дадут об этом знать. только если честно, мне лень их использовать для не проектных работ.

[cfl 0]

Электронная цифровая подпись.

По предидущему - я не в теме. Но в НаноКораде который использует SQLWindowsExpr: положил в базу текстовый файл; отключил базу; открыл базу в тестовом редакторе; нашол текст и запортил его; сохранил базу; Корад работает с базой пока не обращусь к этому файлу - "Обращайтесь к SISу"; SQL делает резервную копию и ничего не говорит. Друг подсказал, что перед резервированием надо утилитой делать проверку. Интересно - все проверяют базу перед резервным копированием?

Электронная цифровая подпись документов на основе JAR архивов.

Используем портированные программы JDK: KeyTool и JarSigner.

Установите JRE 6 с tools.jar в jre\lib\ext\ и Шрифт Arial Unicode MS.

SIGN_1-2.zip

Изменено 6 декабря 2012 пользователем cfl