-
Поскольку подготовительные работы по добавке новой ФС (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.. Но этот момент пока сильно-глубоко в стороне.. Мне бы поддержку вышеописанного нарисовать :)
А так же опять всплывает момент с автоопределением ФС.. Но это тоже пока в сторону - пока только ручное указание ФС
-
Шерстю список (и описание) устройств с прицелом на проверки характеристик (типа размера блока и количества блоков), более полное описание (не только имя устройства но и имя контроллера), выявление тех, кто может быть контейнерами.
Попутно некоторые устройства (с интерлейсом) лишаются своих безинтерлейсных двойников, так как двойники создавались для возможности конвертирования интерлейс->без интерлейса без задания размера для выходного образа, но теперь, с упрощением команды конвертирования, это стало не нежным :)
Ну и как обычно перед серьёзным расширением функционала - был проведён рефакторинг :)
-
Обнаружились неожиданные контейнеры-кандидаты - диски от ОС ОСА от МС-0515, точнее говоря, образы, снятые с обеих сторон :)
-
Проверку и добавление описаний устройств вроде закончил, если только что-то новое после чтения документации всплывёт..
Начинаю эксперименты и доработку под контейнеры, подопытный кролик - DU :)
-
Новостей пока нет - продолжаются рефакторинг, доработки и эксперименты под контейнерными образы.
И думаю над тем, как передавать информацию из командной строки о ФС конкретных частей в контейнере. Пока только вариант - если работа с одной частью контейнера - можно из кс, а если со многими - через файл-описание, но возникает вопрос - как указать, что контейнер и как называется файл описание. Пока склоняюсь в пользу передачи как аргумента ключа с неким именем по умолчанию - примерно сделано для логов с ошибками чтения образа. Но есть некоторая проблема - контейер может быть как на входе, так и на выходе.. Вобщем - думаю..
-
Ещё из мыслей вслух.
ImageUtils была основана на переписанном с С коде TU58fs. И даже сейчас осталось прилично кода, напрямую переписанного оттуда. Как и много идей. Пусть и ImageUtils лишилась функционала - эмуляции TU58 - оттуда.
И одна из особенностей и TU58Em и ImageUtils - образ ЦЕЛИКОМ читается в память. Плюсы - быстрота работы, минусы - если образ большой - то и памяти понадобиться больше :) В принципе, я уже столкнулся с большии образами - самый большой на текущий момент - RSX-11_Freeware_Disk_2.iso - 635 Mб.
Но с образами-контейнерами, я думаю, может всплыть сценарий, когда образ не получится целиком прочитать в память - если образ будет больше 2 Гб. Так как максимальный размер массива в .NET (ну или по крайне мере в C#) - 2 Гб - 1 элемент. И технически такие образы у меня есть - с CF карт :) Тоже есть над чем подумать :)
-
В процессе размышления над реализацией разделов (или секций) образов и то, как работать с ними из командной строки (кстати, мысли есть и в процессе тестовой реализации) вспомнилась одна очень удобная возможность из 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 решил использовать &) - то следующая строка считается продолжением данной - и так пока в очередной строке в конце спец символа нет (или файл закончился) - тогда начинаем обрабатывать команду. Так что можно будет делать ОЧЕНЬ длинные команды, при этом не ухудшая читаемость :)
-
Добавил возможность из одного ККФ вызывать другой ККФ (есть проверка на зациклинность) и устроил комплексное тестирование.
Из неожиданностей - несколько ускорилась работа командного файле комплексного тестирования. Последний вариант работал около получаса, с добавлением ККФ - порядка 15 минут. Технически вроде понятно - ImageUtils вызывается не на каждой команде заново, но все равно - такого не ожидал :) Надо будет восстановить исходный вариант (без ККФ) и сравнить более точно.
Из ожиданностей - пара или тройка.. ну даже не сказать - ошибок, а скорей небрежностей при переносе с C на C# и неучёта того, что парсинг команды начинается не совсем с нуля. Поправил, пока всё ОК
Подведение итогов
Теперь ImageUtils понимает файл с командами (ККФ), команда в ККФ может состоять из нескольких строк (в конце стоит &), один ККФ может ссылаться на другой ККФ.
Появились мысли с добавлением одной или двух команд с прицелом на ККФ, но.. срочной необходимости в них нет - поэтому - потом :)
- - - Добавлено - - -
Со временем выполнения теста ошибся, там помимо ImageUtils работают ещё команды, в частности - сравнение файлов, так что не 15 минут, а 21, но тоже быстрее :)
-
Начал доработку кода именно уже под возможность использовать разделы. С хорошей вероятностью сделано всё до уровня работы с файлами. Но поскольку выделенного уровня нет (спасибо исходной TU58fs).. И поскольку есть ещё интерлейс.. С этим придётся повозиться. В том числе - проверить - не осталось где-то ещё зависимостей от варианта - работаем со всем образом, а не с частью.
Плюсом - рефакторинг, разборки с вариантами дисков с выделенной зоной замены плохих блоков (кодовое назавание - last track devices) - вроде теперь всё сделано правильно, а не вариант - ура, работает, и пофиксил ошибку в выводе подробной информации о ФС - в части информации о физических блоках (если есть отличие от логических блоков).
Из минусов - выходные закончились - времени будет меньше...
-
Пошерстил слегка общение с ФС.. Подправил код чтения из файла и записи в файл и...
Концепт для образов дисков в первом приближении
Код:
>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
Дальше - игры с получившимся результатом на предмет правильности, удобство в использовании и неучтённых нюансов.. :)
