-
В какой-то момент для упрощения командной строки добавил вывод лога операции автоматом в файл. Имя файла лога формируется или по имени выходного файла (если там не каталог Windows) или по имени входного файла (если выходной файл - на самом деле каталог Windows). Всё работало достаточно логично для батников или @-файлов и файлы логов не затирались, если только в командном файле не было одинаковых выходных или входных файлов. Но это как бы уже на совести автора командного файла :)
Всё изменилось с приходом секций :) Теперь имя файла лога может быть одно и тоже для технически разных команд - разные секции :) Поэтому (помимо фиксов ошибок и не учтённых сценариев с секциями) много времени пришлось потратить на вопрос затирания файлов логов. К сожалению - полностью исключить это не удалось (хоть и количество сценриаев сведено к минимуму) поэтому а) файл лога, если он есть, не затирается, а новая информация пишется в конец и б) что бы понять - от какой команды часть лога - перед информацией пишется команда, которая привела к записи последующей инфы.
Возможно, что придумаю варианты формирования лога, которые будут уменьшать вероятность совпадения имени лога, но пока (а может быть и всегда) - так :)
Ну и в планах - сделать возможным ручное указание имени лога для операции. Но это - не в первоочередных планах - пока - секции и ленты BRU :)
-
Вроде текушую концепцию секций добил, теперь попробую добавить ещё один вариант секций (из мира CF) и посмотреть - что вылезет :)
-
Некоторое время повозился с переносом своей (недоделанной) утилиты 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$
Дальше, как обычно - добавка тестов и комплекс тестов :)
-
Немного поигрался с доработками. Из замеченного
- пофиксил ошибку парсинга ФС rsx - в определённом сценарии неверной ФС программа слетает по исключению.
- ошибка парсинга ФС считалась фатальной - то есть программа сразу завершала работу. Счёл поведение неправильным, теперь программа прерывает только текущую операцию, то есть, если идёт работа @-файла - переходим на следующую операцию
- вариант указания секций all теперь работает как диапазон с первой по последнюю секцию - а то был прецедент генерации слишком длинного имени файла
Игры продолжаются
- - - Добавлено - - -
В целом - работа с секционными образами дисков вроде сделана полностью - по крайне мере - что-то нового в плане такого сценария в голову не приходит. Ну, может, что-то придёт в голову или что-то забыл - тогда вернусь в доработку.
А пока - тесты.
Затем - аналог секций для лент - с прицелом в первую очередь на ленты BRU
-
В процесс подсовывания парсеру (теперь RT-11) разного налетел на чем-то похожую на ошибку парсера ФС rsx - в парсере ФС rt. Пофиксил - теперь тоже не падает. В целом - интересное развлечение - подсунуть парсеру ФС образ, который не то что с ошибками в ФС - а вообще с левым содержимым. По хорошему - программа не должна падать. Ругацца, материцца - но не падать :)
-
По тестам вроде ничего не сломалось (что сломалось - починил ранее), так что очередная версия была отправлена в "промышленную" эксплуатацию :) А разработка вернулась к тому, с чего всё началось - к лентам BRU - начинаю второй заход проб :)
-
Для дисков первоначальный вариант работы с секциями работал на уровне чтения отдельных секций - в том числе в плане борьбы с очень большими файлами.
В силу другой организации блочности в образах лент их разбиение на (возможные) секции требует первоначального чтения всего файла.
Пришлось переделать подход. Из сделанного
- Поддержка очень больших (больше 2 гигов) массивов. Теперь могу прочитать целиком в память и файлы размером больше 2 гигов :) .
- Секции в образах дисков теперь не читаются - их объекты мапятся на "сырые", прочитанные из файла, данные и таким образом происходит работа.
Текущий вариант вроде как, по крайне мере, на извлечение данных - работает, но исчерпывающиего тестирования ещё не запускал.
В планах сделать другой вариант реализации сверхбольших массивов - с подкачкой и (при изменении) записью в/из исходного файла. Но не в ближайших планах.
- - - Добавлено - - -
Из занимательного.
Есть образ с ФС RSX на примерно полтора гига. Как оказалось, при его распаковке в виртуалке съедается почти вся память. При этом ImageUtils раздувался до почти 20 гигов =) Надо будет парсинг ODS-1 шерстить - что-то как-то многовато получается памяти в использовании :)
- - - Добавлено - - -
"Out of memory" - класс! Не шмагла :) Где-то утечка памяти :)
- - - Добавлено - - -
Неее. Это ошибка. С утра буду разбираться - где накосячил
- - - Добавлено - - -
Не вытерпел, поковырялся :) Да, это была ошибка. Поправил. Теперь в районе 4.5 гигов потребляет при развертывании этого образа. То есть накладные расходын 4.5-1.7 - 2.8 гига. Многовато (но не 20 гигов), но в принципе понятно - почему так.
Но в процессе работы с образом выяснилось, что новый вариант программы распаковывает его неправильно. Вот теперь точно буду искать ошибку уже утром :)
-
Фиксил ошибки - ляпы и просчёты в сценариях :) Начал гонять тесты. Есть, которые не проходят, но значительная часть уже отрабатывает. В процессе разборок сценариев прилетел философский вопрос. Вроде как в реальной жизни такое не встречал, но... тем не менее. Итак:
- Если у нас есть носитель с программными интерливом и разбиением на секции (ака разделы), то - интерлив должен быть в пределах всего носителя или в каждой секции свой? :)
После раздумий решил, что оба подхода могут иметь место быть, а значит - надо указывать в описании носителя - если используется интерлив, то - какой :)
Пока секционипрование исключает интерлив. Буду выставлять проверку (не случился ли интерлив с секционированием) и если вдруг - ронять программу. Ибо в текущих описаниях устройств такого нет, а если вдруг случится - то это МОЯ ошибка
- - - Добавлено - - -
По результатам - надо проверять секционирование - слетели почти все тесты на эту тему.
Завтра по мере свободного времени :)
-
Поковырялся с утра и в обед. Пара ошибок (вроде) и один недоделанный сценарий. И - вуаля - тесты опять проходят все.
Далее - оценка ущерба (оказалось, что в силу ползучих изменения некоторая часть кода стала.. почти не нужной, так что попутно и её вырезал), причёска кода и тестирование. Если всё ок - очередной коммит
-
Начал потихоньку (времени свободного на неделе мало) парсить ленты, пока в формате BRU.
Этап первый - выделение отдельных backup-ов (ака секций).
Попутно выяснилось, что в рядах образах, в которых секции выделяются на основе данных - пополнение -с екции в ФС Windows. Как-то до начала секционирования лент не задмывался над этим. И тестов на сборку не добавил, так что и с этой стороны подсказки не было. Не страшно - и подход выделения секций похожий и вопрос дальше похоже решать. Так что - попутно сделаю.
