ImageUtils

[Hunta]

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

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

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

Ну и в планах - сделать возможным ручное указание имени лога для операции. Но это - не в первоочередных планах - пока - секции и ленты BRU

[Advertiser]

[Hunta]

Вроде текушую концепцию секций добил, теперь попробую добавить ещё один вариант секций (из мира CF) и посмотреть - что вылезет

[Hunta]

Некоторое время повозился с переносом своей (недоделанной) утилиты CFMaint в общую кодовую базу. Некоторые вещи из неё перенесу в ImageUtils, а так же - есть некоторые задумки по развитию CFMaint (но это потом).

Попробовал добавить схемы секций из того, старого подхода.

Выводы.

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

- Нужна возможность задавать диапазон секций, что то типа 2..10. Не уверен, что пройдёт вариант 2-10, но надо попробовать - этот вариант более приемлем при формировании имен логов

Ну и - в работу пошли образы размером больше 2 Гб, пока, правда, сами секции - меньше, так что пока проблем нет

- - - Добавлено - - -

Одна из причин, пришедших в голову - почему желательна возможность указать диапазон

>dir

 Directory of ...

22.04.2020  22:33     4 017 807 360 001 RT под 1801ВМ3.dsk
18.08.2024  22:59               185 c.cmd
18.08.2024  22:59                 0 log.txt

>type c.cmd 
dir
type c.cmd
ImageUtilsX -unpack "001 RT под 1801ВМ3.dsk" "@001 RT под 1801ВМ3.dsk" s[cf11]:all[]
dir
dir "@001 RT под 1801ВМ3.dsk"

>ImageUtilsX -unpack "001 RT под 1801ВМ3.dsk" "@001 RT под 1801ВМ3.dsk" s[cf11]:all[] 

>dir

 Directory of ...

18.08.2024  23:00            15 046 !Log.txt
22.04.2020  22:33     4 017 807 360 001 RT под 1801ВМ3.dsk
18.08.2024  23:00             2 460 001 RT под 1801ВМ3.dsk.cf11.s000.s001.s002.s003.s004.s005.s006.s007.s008.s009.s010.s011.s012.s013.s014.s015.s016.s017.s018.s019.s020.s021.s022.s023.s024.s025.s026.s027.s028.s029.s030.s031.s032.s033.s034.UnPack.MyLog.txt
18.08.2024  22:59    <DIR>          @001 RT под 1801ВМ3.dsk
18.08.2024  22:59               185 c.cmd
18.08.2024  22:59                 0 log.txt

>dir "@001 RT под 1801ВМ3.dsk" 

 Directory ...\@001 RT под 1801ВМ3.dsk

18.08.2024  22:59        33 554 432 $S000$.$section$
18.08.2024  22:59        33 554 432 $S001$.$section$
18.08.2024  22:59        33 554 432 $S002$.$section$
18.08.2024  22:59        33 554 432 $S003$.$section$
18.08.2024  22:59        33 554 432 $S004$.$section$
18.08.2024  22:59        33 554 432 $S005$.$section$
18.08.2024  22:59        33 554 432 $S006$.$section$
18.08.2024  22:59        33 554 432 $S007$.$section$
18.08.2024  22:59        33 554 432 $S008$.$section$
18.08.2024  22:59        33 554 432 $S009$.$section$
18.08.2024  22:59        33 554 432 $S010$.$section$
18.08.2024  22:59        33 554 432 $S011$.$section$
18.08.2024  22:59        33 554 432 $S012$.$section$
18.08.2024  22:59        33 554 432 $S013$.$section$
18.08.2024  22:59        33 554 432 $S014$.$section$
18.08.2024  22:59        33 554 432 $S015$.$section$
18.08.2024  22:59        33 554 432 $S016$.$section$
18.08.2024  22:59        33 554 432 $S017$.$section$
18.08.2024  22:59        33 554 432 $S018$.$section$
18.08.2024  22:59        33 554 432 $S019$.$section$
18.08.2024  22:59        33 554 432 $S020$.$section$
18.08.2024  22:59        33 554 432 $S021$.$section$
18.08.2024  22:59        33 554 432 $S022$.$section$
18.08.2024  22:59        33 554 432 $S023$.$section$
18.08.2024  22:59        33 554 432 $S024$.$section$
18.08.2024  23:00        33 554 432 $S025$.$section$
18.08.2024  23:00        33 554 432 $S026$.$section$
18.08.2024  23:00        33 554 432 $S027$.$section$
18.08.2024  23:00        33 554 432 $S028$.$section$
18.08.2024  23:00        33 554 432 $S029$.$section$
18.08.2024  23:00        33 554 432 $S030$.$section$
18.08.2024  23:00        33 554 432 $S031$.$section$
18.08.2024  23:00     1 073 741 824 $S032$.$section$
18.08.2024  23:00     1 073 741 824 $S033$.$section$
18.08.2024  23:00       796 581 888 $S034$.$section$

- - - Добавлено - - -

Оказалось даже проще, чем думал. Новый вариант:

>dir

 Directory of ...

22.04.2020  22:33     4 017 807 360 001 RT под 1801ВМ3.dsk
19.08.2024  00:54               202 c.cmd
19.08.2024  00:54                 0 log.txt

>type c.cmd 
dir
type c.cmd
ImageUtilsX -unpack "001 RT под 1801ВМ3.dsk" @"001 RT под 1801ВМ3.dsk" s[cf12]:..4[rt11]:64[rsx]:65[]
dir
dir "@001 RT под 1801ВМ3.dsk"

>ImageUtilsX -unpack "001 RT под 1801ВМ3.dsk" @"001 RT под 1801ВМ3.dsk" s[cf12]:..4[rt11]:64[rsx]:65[] 

>dir

 Directory of ...

19.08.2024  00:55             6 628 !Log.txt
22.04.2020  22:33     4 017 807 360 001 RT под 1801ВМ3.dsk
19.08.2024  00:55           607 982 001 RT под 1801ВМ3.dsk.cf12.s000..s004.s064.s065.UnPack.MyLog.txt
19.08.2024  00:55    <DIR>          @001 RT под 1801ВМ3.dsk
19.08.2024  00:54               202 c.cmd
19.08.2024  00:54                 0 log.txt

>dir "@001 RT под 1801ВМ3.dsk" 

 Directory of ...\@001 RT под 1801ВМ3.dsk

19.08.2024  00:54    <DIR>          $S000$
19.08.2024  00:55    <DIR>          $S001$
19.08.2024  00:55    <DIR>          $S002$
19.08.2024  00:55    <DIR>          $S003$
19.08.2024  00:55    <DIR>          $S004$
19.08.2024  00:55    <DIR>          $S064$
19.08.2024  00:55       796 581 888 $S065$.$section$

Дальше, как обычно - добавка тестов и комплекс тестов

[Hunta]

Немного поигрался с доработками. Из замеченного

- пофиксил ошибку парсинга ФС rsx - в определённом сценарии неверной ФС программа слетает по исключению.

- ошибка парсинга ФС считалась фатальной - то есть программа сразу завершала работу. Счёл поведение неправильным, теперь программа прерывает только текущую операцию, то есть, если идёт работа @-файла - переходим на следующую операцию

- вариант указания секций all теперь работает как диапазон с первой по последнюю секцию - а то был прецедент генерации слишком длинного имени файла

Игры продолжаются

- - - Добавлено - - -

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

А пока - тесты.

Затем - аналог секций для лент - с прицелом в первую очередь на ленты BRU

[Hunta]

В процесс подсовывания парсеру (теперь RT-11) разного налетел на чем-то похожую на ошибку парсера ФС rsx - в парсере ФС rt. Пофиксил - теперь тоже не падает. В целом - интересное развлечение - подсунуть парсеру ФС образ, который не то что с ошибками в ФС - а вообще с левым содержимым. По хорошему - программа не должна падать. Ругацца, материцца - но не падать

[Hunta]

По тестам вроде ничего не сломалось (что сломалось - починил ранее), так что очередная версия была отправлена в "промышленную" эксплуатацию А разработка вернулась к тому, с чего всё началось - к лентам BRU - начинаю второй заход проб

[Hunta]

Для дисков первоначальный вариант работы с секциями работал на уровне чтения отдельных секций - в том числе в плане борьбы с очень большими файлами.

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

Пришлось переделать подход. Из сделанного

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

Текущий вариант вроде как, по крайне мере, на извлечение данных - работает, но исчерпывающиего тестирования ещё не запускал.

В планах сделать другой вариант реализации сверхбольших массивов - с подкачкой и (при изменении) записью в/из исходного файла. Но не в ближайших планах.

- - - Добавлено - - -

Из занимательного.

Есть образ с ФС RSX на примерно полтора гига. Как оказалось, при его распаковке в виртуалке съедается почти вся память. При этом ImageUtils раздувался до почти 20 гигов =) Надо будет парсинг ODS-1 шерстить - что-то как-то многовато получается памяти в использовании

- - - Добавлено - - -

"Out of memory" - класс! Не шмагла Где-то утечка памяти

- - - Добавлено - - -

Неее. Это ошибка. С утра буду разбираться - где накосячил

- - - Добавлено - - -

Не вытерпел, поковырялся Да, это была ошибка. Поправил. Теперь в районе 4.5 гигов потребляет при развертывании этого образа. То есть накладные расходын 4.5-1.7 - 2.8 гига. Многовато (но не 20 гигов), но в принципе понятно - почему так.

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

[Hunta]

Фиксил ошибки - ляпы и просчёты в сценариях Начал гонять тесты. Есть, которые не проходят, но значительная часть уже отрабатывает. В процессе разборок сценариев прилетел философский вопрос. Вроде как в реальной жизни такое не встречал, но... тем не менее. Итак:

- Если у нас есть носитель с программными интерливом и разбиением на секции (ака разделы), то - интерлив должен быть в пределах всего носителя или в каждой секции свой?

После раздумий решил, что оба подхода могут иметь место быть, а значит - надо указывать в описании носителя - если используется интерлив, то - какой

Пока секционипрование исключает интерлив. Буду выставлять проверку (не случился ли интерлив с секционированием) и если вдруг - ронять программу. Ибо в текущих описаниях устройств такого нет, а если вдруг случится - то это МОЯ ошибка

- - - Добавлено - - -

По результатам - надо проверять секционирование - слетели почти все тесты на эту тему.

Завтра по мере свободного времени

[Hunta]

Поковырялся с утра и в обед. Пара ошибок (вроде) и один недоделанный сценарий. И - вуаля - тесты опять проходят все.
Далее - оценка ущерба (оказалось, что в силу ползучих изменения некоторая часть кода стала.. почти не нужной, так что попутно и её вырезал), причёска кода и тестирование. Если всё ок - очередной коммит

[Hunta]

Начал потихоньку (времени свободного на неделе мало) парсить ленты, пока в формате BRU.

Этап первый - выделение отдельных backup-ов (ака секций).

Попутно выяснилось, что в рядах образах, в которых секции выделяются на основе данных - пополнение -с екции в ФС Windows. Как-то до начала секционирования лент не задмывался над этим. И тестов на сборку не добавил, так что и с этой стороны подсказки не было. Не страшно - и подход выделения секций похожий и вопрос дальше похоже решать. Так что - попутно сделаю.