Мониторинг изменений рабочих конфигураций. Часть 1. Сохранение конфигураций из базы SQL без конфигуратора

Администрирование - Сервисные утилиты

Выгружаем исходники из SQL напрямую скриптом, собираем CF и контролируем реальные изменения в рабочих базах из браузера.

Для сохранения конфигурации из 1С в формат CF или в иерархическое дерево исходников в платформе предусмотрен запуск из командной строки. Можно ли сохранить конфигурацию минуя конфигуратор? Можно. Конфигурации находятся в отдельных таблицах SQL-базы.

А зачем это нужно?

Зачем же может понадобиться сохранять конфигурацию столь необычным способом?

  1. Вы хотите знать наверняка, когда и какие изменения внесены в рабочую базу и почему рабочая база не совпадает с конфигурацией хранилища (хотя и должна). 
  2. Оперативный визуальный контроль внесенных изменений без запуска конфигуратора.
  3. Не часто встречающийся случай. Конфигуратор банально занят другим разработчиком, а CF-ник «дозарезу» нужен.  (Сказать разработчику «Ей, Вася, а выгрузи-ка мне CF-ник» вы не можете по нескольким причинам: другой сотрудник не сидит рядом, или отошел на часок, или, возможно, он работает в другом часовом поясе, или вы даже не знаете кто он, а может быть он даже совсем из другой организации-подрядчика и вам сложно найти его контакты через менеджеров.)

Возможно, вы скажете, что причины надуманы и в вашей организации все процессы развертывания совершенны или близки к идеалам. А следующие утверждения иллюстрируют это и всегда (т.е. без исключений!) верны:

  • Ваши разработчики ведут разработку в хранилище.
  • Хотфиксы появляются в рабочей базе только из хранилища. 
  • Хотфиксы всегда проходят тесты (ах, да, тесты!)
  • Никто никогда не вносит изменения в рабочую базу динамически.
  • Если рабочая база подключена к хранилищу ее никогда не отключали по ошибке
  • Никто никогда не спутал рабочий конфигуратор и не накатил туда что-то не то.
  • При сравнении/объединении с новым релизом не бывает ошибки, связанной с неверным выбором файла релиза. Или альтернативное утверждение: новые релизы всегда устанавливаются из файлов поставки.
  • Администраторы базы данных никогда не ошибались с восстановлением БД из других баз данных или бекапов.
  • Мы все одна команда, у нас нет сотрудников, не разделяющих ценности компании, мы уверены, что никто по неведению или злому умыслу не внесет изменений, которые нарушат работу нашей системы.

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

Что понадобится

Кроме 1С будем использовать OneScript (начиная с версии 1.0.16), PowerShell (версии по умолчанию достаточно) и планировщик запуска.

Безусловно, нам нужны права на доступ к SQL-серверу. К нашим конкретным базам данных. Хотя бы на чтение. Исследование будет проводиться на MS SQL-серверах. Для операций будет использован Microsoft SQL Server Management Studio версии 14.0.17119.0 (хотя версия не принципиальна).

Для визуального мониторинга нам потребуется git на сервере, где будет происходить разбор на исходники и учетка в системе контроля версий.

Как хранится конфигурация в SQL

В базе данных есть как минимум две таблицы, отвечающие за хранение конфигурации: [Config], [ConfigSave]. По факту их может быть больше (рисунок из БД на MSSQL)


 
 [Config]- конфигурация БД
 [ConfigSave] – сохраненная конфигурация
 [ConfigCASSave] – сохраненное системное хранилище конфигураций расширений
 [ConfigCAS] –системное хранилище конфигураций расширений

В дальнейшем нас будет интересовать только первая таблица, хотя никто не запрещает анализировать происходящее и в остальных таблицах. Более подробно о том, как хранятся данные можно посмотреть на ИТС: https://its.1c.ru/db/metod8dev#content:1798:hdoc 

Содержимое таблицы Config

Что же внутри Config? Выбрав первые несколько строк и взглянув на названия столбцов убеждаемся, что перед нами двоичные данные: 


  
В процессе исследования мы выяснили, что от версии к версии платформы формат данной таблицы менялся. Для платформы 8.2 таблица имеет следующие столбцы


 
В платформе 8.3 добавился столбец PartNo, который позволил размещать данные неограниченно больших размеров

Разбираем на исходники

Для начала надо сохранить данные на диск. Здесь и далее используются powershell-скрипты. Разбираем двоичные данные, они представляют собой файла заголовка и собственно данные (.header, .data):

 
Для конфигураций на платформе 8.3 скрипт чуть усложняется за счет сбора файлов из нескольких записей. 
В итоге получили папку полную запакованных файлов. С ними уже можно работать при помощи магического и всем известного v8unpack.exe (версия Сергея Батанова
Следующая команда приводит наши файлы к готовому CF-нику: 

Первая часть сделана. Мы получили CF-файл. 

Разобрать его на исходники и поместить в git для последующего визуального контроля нам поможет Gitsync (библиотека для OneScript). Правда, Gitsync работает с файлами хранилища 1С, а у нас на входе есть лишь CF-ник. Поэтому саму библиотеку пришлось слегка поправить, а если быть точным, мы воспользовались уже имевшимся функционалом библиотеки, переделав команду export, убрав из нее работу с хранилищем. 


На выходе мы получаем готовый к помещению во внешний репозиторий комплект исходников:


Делаем git push в заранее подготовленный репозиторий и можем смотреть на то, что изменилось за последнее время. Вот так выглядит типичный коммит после разбора очередного релиза: 


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

powershell –file razbor_upp.ps1 

При наличии изменений в файлах-исходниках git сам «решит», что требуется помещение и сделает его. 
В таком виде мы использовали этот механизм для мониторинга изменений рабочих конфигураций. Но есть, что и улучшить!

Продолжаем автоматизацию

А что если, изменения вносятся не раз в час, а чаще? Или, наоборот, раз в день. Фиксированное время запуска будет помехой. Когда же нужно запускать скрипт? Очевидно, когда база была изменена. А как узнать, что база была изменена? На SQL-базу нужно поставить соответствующий SQL-триггер, который будет инициировать выгрузку в какую-то папку или другую базу и уже потом разбираться.

Кстати, триггер позволит точно ответить на вопрос когда изменилась конфигурация с точностью до секунд.

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

Продолжение следует… 

 

Скачать файлы

Наименование Файл Версия Размер
Архив со скриптами разбора, измененной библиотекой Gitsync
.zip 373,09Kb
28.02.18
10
.zip 373,09Kb 10 Скачать

См. также

Комментарии
1. Андрей Овсянкин (Evil Beaver) 4947 28.02.18 11:12 Сейчас в теме
А чо, весело и задорно! Хотя, заявленные задачи я бы решал другими средствами, но пусть расцветает сто цветов!
Silenser; GreenDragon; +2 Ответить
2. С К (kraynev-navi) 356 28.02.18 11:59 Сейчас в теме
(1) А можно в подробностях?
3. Андрей Овсянкин (Evil Beaver) 4947 28.02.18 12:17 Сейчас в теме
(2) Начнем с того, что не все организационные проблемы надо решать техническими средствами. Организационные меры тоже работают. Одна из лучших мер - отобрать у разработчиков админский доступ к боевой системе. Доступ как в ядерное хранилище - под роспись со сканированием сетчатки и анализом мочи от участкового врача.

Больше подробностей по пунктам задач:

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


Боевая база в режиме "поддержки" с замочками, как типовая. Изменения в ней исключены. Обновление боевой системы выполняет сервер CI с помощью утилиты deployka, а не человек. А если уж человек заходил и изменения в конфигурацию внесены, то есть "конфигурация поставщика", с которой можно сравнить и понять - что изменено. А если сняли с поддержки совсем, так что и "конфигурация поставщика" исчезла - то смотрим журнал доступа и устраиваем показательную казнь.

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

Не понял тезис и задачу. Как выглядит "Оперативных контроль изменений" и что именно решает?

Не часто встречающийся случай. Конфигуратор банально занят другим разработчиком, а CF-ник «дозарезу» нужен. (Сказать разработчику «Ей, Вася, а выгрузи-ка мне CF-ник» вы не можете по нескольким причинам: другой сотрудник не сидит рядом, или отошел на часок, или, возможно, он работает в другом часовом поясе, или вы даже не знаете кто он, а может быть он даже совсем из другой организации-подрядчика и вам сложно найти его контакты через менеджеров.)


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

Теперь по контр-тезисам:

Ваши разработчики ведут разработку в хранилище.


Да, и более того - это совсем не больно. Нет ни одной причины совсем не использовать хранилище в разработке на 1С (если вы не Евгений Сосна, но он использует GIT вместо хранилища, а это не совсем одно и то же, что и вообще без версионирования)

Хотфиксы появляются в рабочей базе только из хранилища.
Да, иначе бардак, Адъ и Израиль. Но бывают авральные хотфиксы, которые потом спокойно и не спеша вносятся в хранилище. Для этого и нужен "режим поддержки" для контроля отличий (см. выше)

Хотфиксы всегда проходят тесты (ах, да, тесты!)
Хотфиксы не проходят тесты, ибо это ХОТ-фиксы, когда пожар и у всех подгорает. Не до тестов.

Никто никогда не вносит изменения в рабочую базу динамически.

Вносят. но это тоже авральный режим. Так не должно быть всегда и инструмент, приведенный в статье здесь непонятно каким боком.

Если рабочая база подключена к хранилищу ее никогда не отключали по ошибке

База не подключена, она стоит на поддержке и за счет этого "неизменна". Включение режима изменений только для авралов. Полное снятие с поддержки - показательная казнь.

Никто никогда не спутал рабочий конфигуратор и не накатил туда что-то не то.

Доступ в боевой конфигуратор человеку (а не серверу CI) только после справки от врача (и желательно с другой машины). Тут сложно перепутать.

При сравнении/объединении с новым релизом не бывает ошибки, связанной с неверным выбором файла релиза. Или альтернативное утверждение: новые релизы всегда устанавливаются из файлов поставки.

Сервер CI не ошибается с выбором файла релиза.

Администраторы базы данных никогда не ошибались с восстановлением БД из других баз данных или бекапов.

И как здесь поможет инструмент, предлагаемый в статье?

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

Нет, мы, напротив, злостные параноики, поэтому пароли от боевых баз у разработчиков отсутствуют.
artbear; user740371; support; amon_ra; Ko1t; vvst; Dementor; VladimirL; IgorS; freddy121; kuntashov; antonj; GreenDragon; jif; kraynev-navi; 1cWin; Bronislav; Berckk; user774630; kalyaka; NeviD; Alexander87; JohnyDeath; +23 Ответить
16. Николай Чуприн (chuprin) 02.03.18 02:26 Сейчас в теме
(3) Очень хороший, годный комментарий. И прямо просит столь же развернутого ответа.
Сразу скажу, что Андрей Овсянкин (Evil Beaver) прав. Нет, ПРАВ!!! На 150%.
И примерно так выглядит наша цель. Цель, к которой мы идем не первый год. Можно прямо брать пост и рисовать RoadMap.

Целью является «Волшебный Мир»с единорогами и розовыми пони. Теми самыми, которые питаются леденцами и какают бабочками. Кто-то уже сумел построить такой мир, кто-то нашел его и переселился. И это здорово, это дарит надежду. Что и остальные из «Злого Леса» могут со временем выбраться в дивный новый мир.
Действительно здорово. Смотришь, например, Infostart Event, и понимаешь, что сообщество растет. То, что когда-то воспринималось как ересь отчаянных гиков, идущих против системы, становится понемногу если не стандартом, то Best Practics.
Есть и плохая новость (на самом деле – не новость). Не везде так здорово. Не всем повезло жить в мире Полудня или НИИ ЧАВО Стругацких. Многие живут в грустном антиутопичном мире, который хорошо описан, например, в цикле статей Ивана Белокаменцева.
https://infostart.ru/profile/73629/
Да и в Gitter есть немало постов про то, что не все гладко.
https://gitter.im/EvilBeaver/oscript-library
И ведь знаешь, как правильно надо делать… Вот и идем мы отсюда – туда, в волшебный мир.
Анекдот про социализм.
http://anekdotov.me/sovetskie/51683-odnoj-nogoj-my-stoim-v-socializme-a-drugoj-uzhe.html
За рамками статьи – много боли. Озера и моря.
Каждый тезис можно развернуть если не в книгу, то в большую статью с примерами из жизни, кульминацией и развязкой.
Собственно, описанный в статье кейс, является решением вполне конкретной жизненной задачи. Кейс этот получил весьма интересное и перспективное развитие. Об этом будет следующая статья.
По поводу «Организационный момент», «показательная казнь», «Сервер CI не ошибается»
У нас холдинговая структура. И, мягко говоря, не всегда можно насадить свое мнение.
Т.е. есть очень уважаемый в организации программист. И незаменимый. То, что незаменимость эта следствие некомпетентности или специально выстроенная ситуация – оставляем за кадром. Так есть. Это реальность, данная нам в ощущениях.
Главное – он полезный. И текущие потребности организации закрывает. И все довольны. А хранилище и регламенты ему не интересны. И даже будут мешать. А вокруг степь на сотни километров и другого все равно не найдем.
И тут какие-то пи… Нет, безусловно, очень умные и грамотные люди из Москвы. К сожалению, оторванные от реальности и не знающие местной специфики, начинают рассказывать, что все не так. Уважаемый человек, на самом деле - вредитель. А то, что раньше делалось за день, будет делаться неделю.
Более того, над людьми (внутренними заказчиками) будет совершаться самое страшное насилие. Их будут заставлять думать. Думать, что же они хотят. Зачем им это надо. Как они будут проверять, что все работает, как они хотели. И, внезапно, появится контроль того, как они используют то что им сделали из того, что они хотели. И апофигеем – анализ достижения целей, которые декларировались, как приоритетные, при аргументации необходимости разработки.
И вот этому «уважаемому человеку» мы собираемся устроить «показательную казнь».
Очень серьезный политический шаг. И за «базар» придется отвечать.
А программист говорит - «мамой клянусь, ничего такого не делал, это все они».
И разговор это очень быстрый. Потом можно долго бегать как в фильме «О чем говорят мужчины» https://www.youtube.com/watch?v=2wcIEybNscs&feature=youtu.be&t=1394
Нужна доказательная база. Вот эту доказательную базу мы и получаем. Да, были изменения в рабочей конфигурации. А в хранилище не было. И задачи на хотфикс не было. Ну как так-то? Ай-яй-яй. Это предметный разговор.
Но, в общем случае, приводить удаленное подразделение к «общему знаменателю» стратегически правильно, но не всегда своевременно и экономически оправданно.
Да и нам это тоже не очень надо. У нас есть маленький кусочек конфигурации, отвечающий за интеграцию. И мы хотим, чтобы он был реализован, работал и не изменялся без нашего ведома.
А вопрос с сопровождением отдельно взятой маленькой недружественной организацией может решиться и естественным путем (например, ее продадут или сократят). Ну да, мы не за идею работаем, тупо за деньги.
Кстати, в волшебном мире такой контроль тоже полезен. На всякий случай. Только в штатной ситуации такое изменение рабочей ИБ должно быть привязано к задаче на деплоймент (в том числе, к автоматической задаче). И это не так сложно промониторить. Определение повода для «показательной казни» тоже можно автоматизировать.
Мне очень нравится идея включить подобный функционал в репозиторий OneScript,но PowerShell тоже имеет аргументы на параллельное существование. Его можно через PsExec запустить удаленно в недружественной среде.
Если нельзя сделать все сразу хорошо – ведь это не значит, что не нужно делать вообще ничего.
Не ожидал, что это скажу, но надо использовать то, что работает.
И вообще, это только кусочек мозаики, паззла. Где есть и безопасность, и мониторинг, и бэкапы, и управление требованиями, и управление задачами, и регламенты, и обучение, и методология, и Framework, и инфраструктура, и организационные изменения, и многое другое.
Еще раз повторю. В комментарии коллеги – все правильно. Просто многих пугает, как жить в переходный период. А здесь работает простое правило бойскаута.
https://plus.google.com/+SergeyTeplyakov/posts/ZaxnrarBvKS
Если каждый день делать немного лучше – в результате неизбежно станет хорошо. Главное, не останавливаться.
support; mr.lynx; Berckk; farukshin; kraynev-navi; tsukanov; Evil Beaver; +7 Ответить
19. Андрей Овсянкин (Evil Beaver) 4947 02.03.18 10:03 Сейчас в теме
(16) Спасибо за камент. Если что - никого не хотел обидеть. Я написал, что статья хорошая, просто я бы решал по-другому, но я не истина в последней инстанции, напротив, мы тут все делимся опытом и каждый делает для себя выжимки из чужого опыта, приправляя своим. Главное потом - не забыть поделиться результатом, чтобы в сообществе было больше разных знаний и опытов. "Пусть расцветает сто цветов" из моего первого комментария - это как раз об этом.

Спасибо за развернутый ответ.
20. Александр Цуканов (tsukanov) 100 02.03.18 11:31 Сейчас в теме
(16) Вот не первый раз вижу как за повершел оправдываются.
Не надо. Все вы правильно делаете
17. Николай Чуприн (chuprin) 02.03.18 02:34 Сейчас в теме
(3)
Не понял тезис и задачу. Как выглядит "Оперативных контроль изменений" и что именно решает?

Тимлид просматривает Gitlab без использования конфигуратора. Обычно, это быстрее и удобнее.
18. Николай Чуприн (chuprin) 02.03.18 02:44 Сейчас в теме
(3)
Не часто встречающийся случай. Конфигуратор банально занят другим разработчиком, а CF-ник «дозарезу» нужен. (Сказать разработчику «Ей, Вася, а выгрузи-ка мне CF-ник» вы не можете по нескольким причинам: другой сотрудник не сидит рядом, или отошел на часок, или, возможно, он работает в другом часовом поясе, или вы даже не знаете кто он, а может быть он даже совсем из другой организации-подрядчика и вам сложно найти его контакты через менеджеров.)

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

Один из печальных кейсов. Запустили обновление ИБ, а там - реструктуризация. Надо было срочно обновляться. Ну как обычно бывает. На тестовый прогон времени не было. А реструктуризация затянулась на несколько часов. Вот тут-то и понадобился CF, чтобы понять, что же там происходит. Прерывать и откатывать на бэкап (да-да, бэкапы перед обновлением делать надо всегда, желательно автоматизированно. Даже внешне самый безобидный деплой может стать фатальным. Ваш КО) или дожидаться реструктуризации.
Тогда обошлись ночной копией. Сейчас бы взяли версию из git/
Evil Beaver; +1 Ответить
21. Эмиль Карапетян (amon_ra) 2 13.04.18 12:53 Сейчас в теме
(3)
Доступ в боевой конфигуратор человеку (а не серверу CI) только после справки от врача (и желательно с другой машины). Тут сложно перепутать.

божечки, какие прекрасные слова! Андрей, можно я тебя буду всем цитировать и сбрасывать на твой комментарий ссылки?)
22. Андрей Овсянкин (Evil Beaver) 4947 13.04.18 16:34 Сейчас в теме
(21) Можешь даже слать мне деньги и ключи от квартир :)
23. Эмиль Карапетян (amon_ra) 2 17.04.18 16:32 Сейчас в теме
(22)с этим сложнее будет)

З.ы. вот я слоупок, только увидел сообщение)
4. ффф ыыы (zqzq) 17 28.02.18 15:00 Сейчас в теме
Вообще, половину проблем решает подключение рабочей базу к хранилищу с минимальными правами (без возможности захвата объектов, только получение из хранилища). Тогда и шаманить в рабочей базе станет физически невозможно, и не спутаешь с тестовой, и сидеть в её конфигураторе тоже никто не будет.

Также автоматизированное обновление рабочей базы из хранилища (нединамическое обязательно) часть других проблем решает.
6. Амир Фарукшин (farukshin) 72 28.02.18 16:03 Сейчас в теме
(4)
половину проблем решает подключение рабочей базу к хранилищу с минимальными правами (без возможности захвата объектов, только получение из хранилища). Тогда и шаманить в рабочей базе станет физически невозможно


К сожалению, не решает. А что помешает в конфигураторе рабочей базы отключить ее от хранилища?
10. ффф ыыы (zqzq) 17 01.03.18 08:52 Сейчас в теме
(6) Я же написал, половину. Неадекватных и злонамеренных сотрудников не рассматриваю, это не техническая проблема, а административная. Если всё так плохо, нужно не пускать в рабочий конфигуратор, как выше писали.
15. Александр Киричков (GreenDragon) 01.03.18 16:17 Сейчас в теме
(10) Вы наверное очень отчаянный человек, если подключаете продакшн базы к хранилищу. Я полтора года назад тоже такую ересь сотворил. В итоге когда упало хранилище, намертво и качественно, мы оказались в ситуации, когда база вроде бы работает, но в конфигуратор продакшн-базы путь заказан - не доходило даже до запроса идентификационных данных хранилища. В итоге был крайне весёлый вечер. По итогу пошли по рекомендуемому многими пути формирования поставки из хранилища. В общем - свят, свят...
5. Сергѣй Батанов (baton_pk) 214 28.02.18 15:56 Сейчас в теме
будем использовать OneScript (начиная с версии 1.0.16), PowerShell (версии по умолчанию достаточно)


прямо больно до слёз! Чего не хватило в односкрипте, чтобы выкинуть из этого списка PowerShell ???

PS. Это не упрёк, а вопрос - мы же допилим, если что :)
starik-2005; JohnyDeath; kraynev-navi; Evil Beaver; STivO; +5 Ответить
7. Андрей Овсянкин (Evil Beaver) 4947 28.02.18 17:03 Сейчас в теме
(5) И во вложениях - доработанный gitsync. А что именно доработано? Может это включить в основной gitsync?
8. Сергѣй Батанов (baton_pk) 214 28.02.18 17:26 Сейчас в теме
(7)
переделав команду export, убрав из нее работу с хранилищем.

Видимо, это. То есть, гитсинк тут и не нужен, нужен мелкий скрипт с v8runner и gitrunner.
artbear; МихаилМ; +2 Ответить
13. Николай Чуприн (chuprin) 01.03.18 12:25 Сейчас в теме
(5)
Чего не хватило в односкрипте, чтобы выкинуть из этого списка PowerShell ???

Все просто. Задача стояла - получить из SQL cf, валидный для разбора в git. Первым по запросу "BLOB поле в файл" попался PS-скрипт. Конечно, можно то же самое реализовать в односкрипте. А если функционал будет добавлен в гитсинк, то мы первые начнем пользоваться.
9. Василий Казьмин (awk) 688 28.02.18 23:21 Сейчас в теме
Разворчались... У меня тестовый контур, и кф файл нужен из бызы разработчика, для базы тестирования... А согнать разработчика с отладки, что бы тестировщик что-то обновил... Так что плюс однозначный...
12. Михаил Максимов (МихаилМ) 01.03.18 09:27 Сейчас в теме
(9)
для этого данный инструмент необязателен.
достаточно написать скрипт создания пустой базы , копирования из рабочей конфиг в пустую, выгрузку цф.
11. Михаил Максимов (МихаилМ) 01.03.18 09:24 Сейчас в теме
(0)
перепишите скрипт так чтобы он сразу раскладывал по папкам с понятными названиями.
14. Юрий Пермитин (YPermitin) 633 01.03.18 15:23 Сейчас в теме
Однозначно +!
За PowerShell вторую бы звезду поставил :)
awk; tsukanov; +2 Ответить
Оставьте свое сообщение