ImageUtils

[Hunta]

Поскольку подготовительные работы по добавке новой ФС (BRU+ODS1+ лента или диск) практически закончены, начал было вчера потихоньку писать код и в процессе приходит мне в голову мысль..

Мало того, что в образе (и диска и ленты) может быть несколько бэкапов BRU, а на ленте, технически, ещё и в перемежку идти не только данные от разные программ (на вскидку - ROLLIN, PRE, BRU и вроде как DSC), но ещё и просто файлы.

Скажем, лента BRU - это лента в формате ANSI (не помню, как он правильно у буржуинов называется, в нашем случае - это вроде ГОСТ 25752-83), так что там могут быть и простые файлы.

На диске с бэкап-сетами BRU создается файловая система ODS-1 (ака RSX) с единственным файлом BACKUP.SYS, который, насколько я знаю, иммитирует ленту.

Ну и так же есть диски MSCP, которые RT-11 умеет "бить на разделы", а так же мои CF, на которых могут быть одновременно и разделы с ФС RT и разделы с ODS-1.

А что бы окончательно добить.. Бэкап-сеты BRU (и возможно ROLLIN, PRE и DSC - тут не скажу, надо копаться в исходниках и доках) могут многотомными - то есть несколько лент или дисков (вон, для отладки ImageUtils валяется многодисковый бэкапсет MicroRSX образов RX50)

Вобщем, покрутив всё это безобразие в голове, пришёл к выводу, что в ImageUtils надо сначала добавить понятие Контейнер. Который сначала будет биться на отдельные образы в нём, а потом уже с образом будет разборка - какая ФС и что с ней хотят делать. Ну и плюс возможность - контейнер разобрать на отдельные образы и сохранить их в файлы. Или наоборот - из файлов собрать контейнер. Что то похожее я начал делать в программе CFMaint, но не все задумки закончил. Теперь, похоже, всё это плавное перейдёт в ImageUtils

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

Думаю дальше...

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

А ещё вспомнилось, что есть у меня SD-шки от PDP-11X - тоже контейнеры, только уже устройств (пока RK05 и RL02, но там ещё и RP были у автора)

А потом пришло в голову, что на CF могут быть и XXDP/DOS-11 разделы (стоит только написать драйвер CF для этих систем)...

А ещё есть RSTS.. А ещё есть другие ОС и не только от DEC.. Но этот момент пока сильно-глубоко в стороне.. Мне бы поддержку вышеописанного нарисовать

А так же опять всплывает момент с автоопределением ФС.. Но это тоже пока в сторону - пока только ручное указание ФС

[Hunta]

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

Попутно некоторые устройства (с интерлейсом) лишаются своих безинтерлейсных двойников, так как двойники создавались для возможности конвертирования интерлейс->без интерлейса без задания размера для выходного образа, но теперь, с упрощением команды конвертирования, это стало не нежным

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

[Hunta]

Обнаружились неожиданные контейнеры-кандидаты - диски от ОС ОСА от МС-0515, точнее говоря, образы, снятые с обеих сторон

[Hunta]

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

[Hunta]

Новостей пока нет - продолжаются рефакторинг, доработки и эксперименты под контейнерными образы.

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

[Hunta]

Ещё из мыслей вслух.

ImageUtils была основана на переписанном с С коде TU58fs. И даже сейчас осталось прилично кода, напрямую переписанного оттуда. Как и много идей. Пусть и ImageUtils лишилась функционала - эмуляции TU58 - оттуда.

И одна из особенностей и TU58Em и ImageUtils - образ ЦЕЛИКОМ читается в память. Плюсы - быстрота работы, минусы - если образ большой - то и памяти понадобиться больше В принципе, я уже столкнулся с большии образами - самый большой на текущий момент - RSX-11_Freeware_Disk_2.iso - 635 Mб.

Но с образами-контейнерами, я думаю, может всплыть сценарий, когда образ не получится целиком прочитать в память - если образ будет больше 2 Гб. Так как максимальный размер массива в .NET (ну или по крайне мере в C#) - 2 Гб - 1 элемент. И технически такие образы у меня есть - с CF карт Тоже есть над чем подумать

[Advertiser]

[Hunta]

В процессе размышления над реализацией разделов (или секций) образов и то, как работать с ними из командной строки (кстати, мысли есть и в процессе тестовой реализации) вспомнилась одна очень удобная возможность из RSX (что-то похожее есть и в RT-11) - косвенные командные файлы. Итак, встречаем:

>type stest.cmd

  ImageUtilsX @icf

>type icf.cmd

  -unpack Src\11SKIT1_try1.tap                1\@11SKIT1_try1.tap     dos11 tape
  -from   1\@11SKIT1_try1.tap  Path WinFS -to 1\11SKIT1_try1.Pack.tap tape  dos11

>stest.cmd

  ImageUtilsX @icf

    [2024-Jul-26 00:01:55 info   ]  'Src\11SKIT1_try1.tap' proceeding...
    [2024-Jul-26 00:01:58 info   ]  '1\@11SKIT1_try1.tap' proceeding...
    [2024-Jul-26 00:01:58 info   ]  initialize empty WinFS file system on "1\@11SKIT1_try1.tap"
    [2024-Jul-26 00:01:58 info   ]  Converting...
    [2024-Jul-26 00:01:58]          Files from "Src\11SKIT1_try1.tap" written to "1\@11SKIT1_try1.tap".
    [2024-Jul-26 00:01:58]          00:00:03.1703666
    [2024-Jul-26 00:01:58 info   ]  '1\@11SKIT1_try1.tap' proceeding...
    [2024-Jul-26 00:01:58 info   ]  '1\11SKIT1_try1.Pack.tap' proceeding...
    [2024-Jul-26 00:01:58 info   ]  initialize empty DOS11 file system on "1\11SKIT1_try1.Pack.tap"
    [2024-Jul-26 00:01:58 info   ]  Converting...
    [2024-Jul-26 00:02:00]          Files from "1\@11SKIT1_try1.tap" written to "1\11SKIT1_try1.Pack.tap".
    [2024-Jul-26 00:02:00]          00:00:02.1844931

>dir 1

   Volume in drive ... is .....
   Volume Serial Number is .....

   Directory of ...\1

  26.07.2024  00:02    <DIR>          .
  26.07.2024  00:02    <DIR>          ..
  26.07.2024  00:02         1 987 852 11SKIT1_try1.Pack.tap
  26.07.2024  00:02            14 434 11SKIT1_try1.Pack.tap.FromFsToFs.MyLog.txt
  26.07.2024  00:01    <DIR>          @11SKIT1_try1.tap
                 2 File(s)      2 002 286 bytes
                 3 Dir(s)  159 370 285 056 bytes free

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

В общем, в реализации не сильно много кода, наваял и отладил где-то за час В основном - время занял парсинг строк из ККФ по аналогии с Windows.

Так же была реализована (но ещё не оттестирована) и идея строк с продолжением - то есть если в конце строки определённый символ (в RSX, ЕМНИП - тире, для ImageUtils решил использовать &) - то следующая строка считается продолжением данной - и так пока в очередной строке в конце спец символа нет (или файл закончился) - тогда начинаем обрабатывать команду. Так что можно будет делать ОЧЕНЬ длинные команды, при этом не ухудшая читаемость

[Hunta]

Добавил возможность из одного ККФ вызывать другой ККФ (есть проверка на зациклинность) и устроил комплексное тестирование.

Из неожиданностей - несколько ускорилась работа командного файле комплексного тестирования. Последний вариант работал около получаса, с добавлением ККФ - порядка 15 минут. Технически вроде понятно - ImageUtils вызывается не на каждой команде заново, но все равно - такого не ожидал Надо будет восстановить исходный вариант (без ККФ) и сравнить более точно.

Из ожиданностей - пара или тройка.. ну даже не сказать - ошибок, а скорей небрежностей при переносе с C на C# и неучёта того, что парсинг команды начинается не совсем с нуля. Поправил, пока всё ОК

Подведение итогов

Теперь ImageUtils понимает файл с командами (ККФ), команда в ККФ может состоять из нескольких строк (в конце стоит &), один ККФ может ссылаться на другой ККФ.

Появились мысли с добавлением одной или двух команд с прицелом на ККФ, но.. срочной необходимости в них нет - поэтому - потом

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

Со временем выполнения теста ошибся, там помимо ImageUtils работают ещё команды, в частности - сравнение файлов, так что не 15 минут, а 21, но тоже быстрее

[Hunta]

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

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

Из минусов - выходные закончились - времени будет меньше...

[Hunta]

Пошерстил слегка общение с ФС.. Подправил код чтения из файла и записи в файл и...
Концепт для образов дисков в первом приближении

>dir 1 

   Directory of 1

  29.07.2024  15:33    <DIR>          .
  29.07.2024  15:34    <DIR>          ..
  29.07.2024  14:31    <DIR>          @m013-0.dsk
  29.07.2024  14:46    <DIR>          @m013-1.dsk
                 0 File(s)              0 bytes
                 4 Dir(s)  159 373 152 256 bytes free

>ImageUtilsX -pack 1\@m013-0.dsk 1\m013.Test.dsk schema:du p:0 rt11 

>ImageUtilsX -pack 1\@m013-1.dsk 1\m013.Test.dsk s:du partition:1 rt11 

>ImageUtilsX -dir 1\m013.Test.dsk s:du p:0 rt11 

>ImageUtilsX -dir 1\m013.Test.dsk s:du p:1 rt11 

>dir 1 

   Directory of 1

  29.07.2024  15:34    <DIR>          .
  29.07.2024  15:34    <DIR>          ..
  29.07.2024  14:31    <DIR>          @m013-0.dsk
  29.07.2024  14:46    <DIR>          @m013-1.dsk
  29.07.2024  15:34        67 108 864 m013.Test.dsk
  29.07.2024  15:34               390 m013.Test.dsk.du.p0.Dir.MyLog.txt
  29.07.2024  15:34               312 m013.Test.dsk.du.p0.Pack.MyLog.txt
  29.07.2024  15:34               608 m013.Test.dsk.du.p1.Dir.MyLog.txt
  29.07.2024  15:34               538 m013.Test.dsk.du.p1.Pack.MyLog.txt
                 5 File(s)     67 110 712 bytes
                 4 Dir(s)  159 306 035 200 bytes free

>type 1\m013.Test.dsk.du.p0.Dir.MyLog.txt 

  FDF331.DOC   302      27-OCT-1989      FDF333.DOC   118      27-OCT-1989
  FILE  .BAD     1      09-FEB-1990       EMPTY.FIL 65088 D               
   4 files, 421 blocks
   65088 Free blocks


>type 1\m013.Test.dsk.du.p1.Dir.MyLog.txt 

  DDP278.LDA    38      13-FEB-1974      DDU278.LDA    39      13-FEB-1974
  LDP278.LDA    35      13-FEB-1974      LDU278.LDA    35      13-FEB-1974
  NDP278.LDA    37      13-FEB-1974      NDU278.LDA    37      13-FEB-1974
   EMPTY.FIL 65246 D               
   7 files, 221 blocks
   65246 Free blocks

Дальше - игры с получившимся результатом на предмет правильности, удобство в использовании и неучтённых нюансов..