ODS1 FILES-11 DECFILES11A reader

ods1reader - разбор образов дисков с FILES11-структурой: https://www.dropbox.com/s/f0ewfhrvhw...ods1reader.zip v.1.05 (03-04-2020)
Нужна изредка, но пусть будет отдельной темой, т.к. ODS-1 (On Disk Structure Level 1) — формат файловой системы использовался на разных машинках с корнями от d|i|g|i|t|a|l.
Может быть полезна для просмотра образов с RSX/Micro-RSX, P/OS и ПРОС. Идентификатор DECFILE11A или DFCFILE11A.
У файлов может оказаться по несколько разных имен (как они описаны в директории-родителе, и личной инфе). Подсвечиваются болдом при несовпадении (правый клик мыши покажет альтернативное имя).
Извлекает все файлы, в т.ч. удалённые, из дампа диска общей кучей в один каталог C:\OUT\
В исходные дампы никакие изменения никогда не вносятся, для них жестко задан режим только чтение.
При извлечении дополнительно разворачиваются текстовые файлы со строчным кодированием (f.rtyp == R_VAR), добавляя к имени файла-оригинала ".txt".
"c:\out\zzlog.txt" - полный лог парсинга. "c:\out\zzcut.dat" - "форк-минусовка" (копия дампа в которой незанулены только те сектора которые оказались недоступны через дерево файловой системы данного диска).
По моему личному предпочтению, на данный момент:
.DSK и .DZ - это образ дискеты в формате DZ (409'600 байт).
.IMG - это образ такой же дискеты, только сектора идут уже нормально последовательно - бут блок самый первый и т.д.
.RD - образ жесткого диска у которого бут блок чуть сдвинут, а в начале идёт пустой сектор.
Длина файла .img в общем-то может быть любой, так как и .dsk/.dz и .rd в итоге сводятся к .img, который есть LBN.
Внутреннее предперекодирование секторов происходит опираясь только на расширение выбранного файла-образа, зададите неправильно - могут быть чудеса.
P.S. Чудеса зависят от разных факторов. Поэтому если не открывается то, что должно открываться - прошу в личку, скайп или на мыло.
https://img-fotki.yandex.ru/get/3664...c7299c40_L.png
При извлечении (в C:\OUT) файлов с одним именем, расширением и номером ревизии, но из разных директорий образа, они перезапишутся друг поверх друга по мере встречи, но это можно отключить галочкой. Выбрать принудительное сохранение нужного можно из контекстного меню.

Умеет вытаскивать правильно? (с учетом структуры FILES-11)?
Особенно ксается файлов текстовых и бинарных (OBJ, STB) - должны при вытаскивании конвертиться в формат RT-11.

Так для миграции используется FLX. А я сохраняю содержимое 1-в-1 как записано на диске(те), что бы, максимально, в человеческом виде.
Если предварительно обработать FLX-ом, то оно тогда будет извлечено уже готовым к переносу с учетом его соглашения о форматировании.
Помнишь ты мне сбрасывал специально для тестов ttdrv.stb. Там всё это хорошо было видно по служебным полям.
З.Ы. Есть ли необходимость переписать FLX под винду/консоль? Тогда файлики смогут красиво копироваться дальше в TC-плагине Patron'а.

https://img-fotki.yandex.ru/get/5798...d0dab552_L.png
/*
Из аттача с образом RX50 (не прошным).
В нем в [1,1] лежат TTDRVRSX.STB - родной RSXовский STB файл и TTDRVRT.STB - он же, скопированный FLX'ом в RT-11 и вытащенный оттуда в IMAGE mode.
Вроде в описании утилиты FLX написано что делается при конвертации таких файлов.
Примерно так - когда копируется за пределы FILES-11, в начало каждой записи добавляется ее длина, а в конец - контрольная сумма.
*/

Исходник (плюс его текстовая колбаса):
Filename: [87,1] ttdrvrsx .stb;1 ;0 # № 8, LBN: (11)
f_rtyp R_VAR - text
f_ratt FD_NONE - save content as is
f_rsiz - used Record Size value in bytes: 122 (p.6.3.1) == HEX: 7A 00

А вот так он выгружается при экспорте:
Filename: [87,1] ttdrvrt .stb;1 ;0 # № 7, LBN: (3)
f_rtyp R_FIX - fixed binary or stream
f_ratt FD_CR - use Normal slew: LF before line data, CR after
f_rsiz - used Record Size value in bytes: 512 (p.6.3.1)

Цитата:

---

Сообщение от anasana

.DSK - это образ дискеты в формате DZ (409'600 байт).
.IMG - это образ такой же дискеты, только сектора идут уже нормально последовательно - бут блок самый первый и т.д.

---

Вот это, в обшем говоря, неправильно. По-хорошему, .DSK, как уже сложилось, должен быть простым линейным файл-образом. На что, кстати, намекают и файлы логических дисков RT-11.

Для образа дискеты DZ следовало бы выбрать какое-то другое расширение - например, .DZ, подобно тому, как Патрон сделал .DW для ДВК-шного винчестера. Пока еще не сильно поздно, стоило бы переиграть. И в Хомере, кстати, тоже.

Цитата:

---

Сообщение от anasana

dw и dz добавил

---

Стоп-стоп! .DW зарезервировано за ДВК, для Э-85 положено .RD. Если не в курсе, у ДВК сначала делением вычисляют C-H-R, потом инкрементируют R по модулю 16, а у 85-й инкрементируют номер блока, потом делением получают C-H-R. В итоге у Э-85 на один сектор сдвинут весь диск, а у ДВК на один сектор сдвинута дорожка, а блоки 15, 31, 47, 63... оказываются в нулевом секторе соответствующей дорожки.

Цитата:

---

Сообщение от AFZ

у ДВК на один сектор сдвинута дорожка, а блоки 15, 31, 47, 63... оказываются в нулевом секторе соответствующей дорожки.

---

Так было и на всех советских Э-85 с RT-11 - "заворот дорожки" DW в RT-11 исправлен только с V05.03, а на советских Э-85 стояла V05.01

Цитата:

---

Сообщение от anasana

Да, согласен, - это хорошая идея. Посижу, пострадаю немного локально в размышлениях - dw и dz добавил, а dsk пока ещё не отдал, т.к. слишком много переименовывать сейчас не готов.

---

Уточни пожалуйста ещё разок, что там с расширениями в итоге, .DSK - должны быть RT-шки, как тут описано

Цитата:

---

Сообщение от AFZ

Вот это, в обшем говоря, неправильно. По-хорошему, .DSK, как уже сложилось, должен быть простым линейным файл-образом. На что, кстати, намекают и файлы логических дисков RT-11.

---

- - - Добавлено - - -
Попытка запуска в XP sp3

http://storage8.static.itmages.ru/i/...9658d63a4a.png

Цитата:

---

Сообщение от Patron

Так было и на всех советских Э-85 с RT-11 - "заворот дорожки" DW в RT-11 исправлен только с V05.03, а на советских Э-85 стояла V05.01

---

Не-а! Это было всегда. Собственно, эта глупость была затеяна из-за того, что БИОС ПРОхи, а, следовательно и 85-й, в процессе запуска, производит какую-то тестовую запись на винчестере, для чего ему пожертвовали дорожку 0-0-0, а остальной диск сдвинули. Не сделай они этого изначально, диск DW, в точности, как и RK, начинался бы с 0-0-0.

А наши ДВК-шники (Зеленоград), не въехав в суть этого дела и, вероятно, не зная RK, зато насмотревшись на дискеты и поразглядывав винт от 85-й, решили, что загрузочный сектор всегда должен быть 0-0-1, остальное интерпретировали по-своему. Исправили они эту ошибку, или нет, точно не знаю. Я видел в поставке с ДВК только ФОДОС, который был сделан из 5.1. Контора, в которой я тогда работал, получила в 1994-м кучку ДВК, они были с тем же ФОДОСом. Подозреваю, это была вообще одна из последних поставок ДВК с Кванта. То есть, конечно, они еще пытались продавать свой АДОС, не знаю, ни разу не пытался его ставить и понятия не имею, какой там DW, но подозреваю, что DW для ДВК, совместимый по расположению дорожек с Э-85 - чья-то самодеятельность, есть у меня где-то и такой, причем, действительно, не то с 5.3, не то с 5.4. DEC'овского же DW для ДВК не было и не могло быть, поскольку таких контроллеров для Q-Bus у них никогда не было, это целиком наша (зеленоградская) самодеятельность.

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

Да, вспомнил. Я все-таки загружал АДОС, с дискеты. И этот АДОС вполне нормально видел мой винчестер, который "с заворотом". Так, что ни разу Зеленоград этот "заворот" не убирал. Оно и понятно: допустим, купил кто-то у них этот АДОС, ставит его на свой винт, где был ФОДОС, и обнаруживает, что содержимое винта пошло лесом. Да он же пойдет бить им морды!..

А ходившие в народе ДВК-шные драйвера DW с 85-м порядком секторов - чей-то самопал, точно.

Цитата:

---

Сообщение от AFZ

Не-а! Это было всегда.

---

Всегда - на ДВК. Но речь про Э-85 и про то, что вплоть до RT-11 V05.03 - на Pro350 ( а значит - и на Э-85 ) был точно такой же "заворот дорожки" DW.

Дековцы исправили "заворот дорожки" только в родном драйвере DW для RT-11 V05.03. До того момента - винчестеры с RT-11 во всём мире ( включая все Pro350 и все Э-85 ) были в точности с таким же "заворотом дорожки", как у ДВК.

Цитата:

---

Сообщение от Patron

Всегда - на ДВК. Но речь про Э-85 и про то, что вплоть до RT-11 V05.03 - на Pro350 ( а значит - и на Э-85 ) был точно такой же "заворот дорожки" DW.

---

Поглядел - точно. Блин, и на хрена они это сделали? Глядя на других? Так ведь у них контроллер уникальный, у других нулевого сектора просто не было - они начинались с 1 и где как - на простых MFM - до 17, на RRL - поболее, помнятся цифры 22, 28, 39, еще что-то, но нулевого сектора нигде не было. А тут 0-15, на хрена, спрашивается, было извращаться? Чтобы делать ошибки в драйверах?

Цитата:

---

Сообщение от AFZ

у других нулевого сектора просто не было

---

RK05? :)

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

Цитата:

---

Сообщение от AFZ

на хрена, спрашивается, было извращаться?

---

Возможно для простоты расчетов. Меня больше поражало (до момента когда удалось подтвердить предположение) зачем в то время когда уже было сказано, что дальше будет MSCP, изхобретать левые контроллеры. Но когда при переносе фич из M+ 3.0 в P/OS 3.0 совершенно откровенно самое полезное было проигнорировано, а целая полезная директива в остальном функционале была сохранена, но заменена на другую (полностью аналогичную, но несовместимую бинарно и иначе назыывавшуюся) все стало ясно, а позже удалось и прямо услышать об этом :)

Цитата:

---

Сообщение от form

RK05?

---

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

Цитата:

---

Сообщение от form

Возможно для простоты расчетов.

---

Ага, два раза! Что может быть проще одной команды BIC #177760,Rx ? Это если использовать естественный порядок секторов, т.е. блок 0 имеет C-H-R = 0-0-0, блок 1 - 0-0-1 и т.д. Любой другой способ установления соответствия между номерами блоков и номерами секторов потребует каких-то дополнительных команд. Так, что это явно сделано не для простоты, а наоборот, для усложнения расчетов. Где они и облажались!..

Цитата:

---

Сообщение от AFZ

Что может быть проще одной команды BIC #177760,Rx

---

Отсутствие таковой в виду ее ненадобности? ;)

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

Да, но вернемся к главной теме (к коей никак не относится ни порядок секторов где-то там ни нумерация таковых)... Насчет реадера - так-таки он научился делать реверсивное извлечение данных? - то есть чтобы потом возможно было вернуть эти данные обратно в FILES-11. На мой взглад по прежнему остается единственный простой вариант - конвертирование при извлечении в формат RT-11 (он же по сути все прочее интеловское), а при записи обратно соответственно - обратная конвертация. Как вариант, конечно возможны варианты (тьфу!) с использованием ea, streams или доп файлов, но они не позволяют работать с извлеченными файлами вне родной среды...

Цитата:

---

Сообщение от anasana

Когда извлечение с конверсией в RT-11 доделаю

---

Тут не все так просто. Есть привычный набор расширений (который пользует например FLX), его можно расширить, но в конечном счете должен быть вариант ручного указания варианта (ррр) преборазования (ASCII, BINARY, IMAGE). Самое интересное - binary (OBJ, STB, LDA итд) - при правильной конверсии получим правильные файлы (хотя STB с точки зрения RT-11 правильно использовать почти невозможно [хоть линк и делать их умеет]).

Цитата:

---

Сообщение от anasana

А какие подводные камни могут быть в случае если мы из FILES-11 образа А брём содержимое как оно есть, и кладём в FILES-11 же образ Б

---

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

anasana, Если пожелания принимаются, то можно сделать окно масштабируемым. А то слишком большое поле окна где нет никакого функционала. Наверняка где-то есть уже готовые шаблоны окон.
Или лучше сделать плагином под Т.С.
Спасибо.

Цитата:

---

Сообщение от anasana

Пока идёт работа над более интересным проектом, да и запись ещё не отлажена, работу читалки через интерфейс ТС отложу на закуску.

---

В топку TC!

FAR рулит!

Цитата:

---

Сообщение от AFZ

В топку TC!

---

А ТС у вас на русском или на английском? :-D

Пятничное обновление извлекалки, описания и ссылки на новую версию в первом сообщении.

Пятничное обновление. Т.к. для этого образа диска:

Цитата:

---

Сообщение от MiX

Образ- здесь.
...

---

оказалось имеет смысл добавить режим не перезаписывать файлы поверх с одинаковыми именами, т.к. текстовый редактор меняет имена файлов в описаниях директорий, а в информации о файле у всех всё так и остается имя "zzredakof.sys".
В образе их оказалось больше сотни разных по содержимому. (для этого надо убрать галочку Overwrite)
https://pic.maxiol.com/thumbs2/15859...3174.mixrd.png https://pic.maxiol.com/thumbs2/15859...3174.mixrd.png

Я так понимаю, что начиная с RQDX3 в нулевом цилиндре нулевой дорожке нулевого сектора контроллер хранит геометрию диска. Проверить можно, посмотрев исходники фирмваре контроллера. Но предположение достаточно логичное :)

Небольшой апдейт, который требует тестирования, т.к. вносит изменения в образ, - удаление файлов из дампа.

Отсюда просьба погонять на своих копиях, т.к это неспешная подготовка к возможности добавления файлов на диски с ODS-1.
если нажать на чекбокс "Image r/o" (по умолчанию - режим: только чтение),
то он сменится на "Image r/w" в котором в смонтированном образе можно по одному удалять файлы, пустые каталоги и изменять метку тома на диске.
изменения вносятся сразу же, поэтому просьба, и это важно, - работать исключительно с копиями Ваших дампов!

как проверять изменения: сравнением по содержимому лог-файла отчёта zzlog.txt с до и после удалений - отличия будут заметны и детализированы.
Наверно позже дополню эту заметку описанием в какие именно области дампа вносятся правки.

Скачать тестовую сборку можно отсюда: https://www.dropbox.com/scl/fi/u023t...tvdhrg894&dl=0
... традиционно пожелания и багрепорты предпочтительней отправлять мне напрямую

Причёсывая извлекалку добрался до рефакторинга вывода списка "плохих" блоков на томе, ну и реальный дамп у себя отыскал у которого "не всё чисто", подходящий для тестов.
В мануале DEC Files-11_ODS-1_Spec раздела описания badblk.sys указана особая структура всегда размером 512 байт (1 сектор что для дискеты, что для огромных жестких дисков), расположенная в самом последнем живом секторе на диске, тут, если с нуля, - 799 или же он же 800-й (размер дискеты 409600 байт)

"Virtual block 1 of the bad block file is the bad block descriptor for the volume.
It is always located on the last good block of the volume.
...
This block is included in the bad block file to save the data it contains for future re-initializations of the volume."

где есть поле о количестве плохих секторов диска, (здесь их было заявлено: 3)
и далее перечислением идёт их типа список (max. 126 шт.):
List of volume bad blocks (showed LBN's marked as damaged):
777, 780, 788
end
и в конце поле контрольной суммы (badmh B_CHK1).

В базе файл-карты занятых полезными данными секторов (bitmap.sys) это выглядит вот так:

Код:

---

Map of used blocks (showed LBN's marked as free):
(начало диска, обычно сектора плотно зазаняты)
  ,    ,    ,    ,    ,    ,    ,    ,    ,    ,
...
(и под конец чаще уже посвободнее)
760, 761, 762, 763, 764, 765, 766, 767, 768, 769,
770, 771, 772, 773, 774, 775, 776,    , 778, 779,
  ,    ,    , 783, 784, 785, 786, 787,    , 789,
790, 791, 792, 793, 794, 795, 796, 797, 798,    ,
end

---

логично, что указанные "несвободные" damaged 777, 780, 788 - запрещено использовать т.к. они "плохие", ну и последний 799 в нём о них инфа и хранится.

а теперь внимательно смотрим за руками:
собственно заголовок самого файла badblk.sys этой дискеты хранит список указателей на приналдежащие ему, как любому обычному файлу, сектора
Filename: [1,1] badblk .sys;1 ;0 #№ 3 lifetime seq: 3, 1stLBN:(5:777) [RWED,RWED,RWED,RWED] Rev.date: Rev.time: Creat.date: 30JAN92 Creat.time: 154512 Expirat.date:
filnum H_CKSM: 3D83 - OK
filnum 3 exsist
Fileitem nullsized
Segment 1. Chunk LBN's: 777 (512 bytes at last) | 777, higblk: 0, eofblk: 0, vbncounter: 1
Segment 2. Chunk LBN's: 780 781 782 (512 bytes at last) | 782, higblk: 0, eofblk: 0, vbncounter: 4
Segment 3. Chunk LBN's: 788 (512 bytes at last) | 788, higblk: 0, eofblk: 0, vbncounter: 5
Segment 4. Chunk LBN's: 799 (512 bytes at last) | 799, higblk: 0, eofblk: 0, vbncounter: 6
badmh B_CHK1: 0A30 - OK

т.е. badblk.sys "храня в себе" "замыкает на себя" (сбойные?) сектора дискеты 777 780 781 782 788 и, собс-но, инфо-тело со структурой, в 799

Код:

---

Map of used blocks (showed LBN's marked as free):
  ,    ,    ,    ,    ,    ,    ,    ,    ,    ,
...
770, 771, 772, 773, 774, 775, 776, BAD, 778, 779,
BAD, BAD, BAD, 783, 784, 785, 786, 787, BAD, 789,
790, 791, 792, 793, 794, 795, 796, 797, 798,    ,
end

---

вот так элегантно придумано блочить скомпрометированные сектора у носителей любых размеров, и здесь их по факту вероятно "плохих" секторов целых пять, а не три?
думаю, стоит разыскать больше таких реальных примеров, а то я мог сделать неверные выводы.

Что-то где-то мне вроде попадалось во времена более плотной работы на СМ-1420, что блок-описатель (тот, который в конце тома) может быть и не один.. Но с учётом прошедшего времени (это было начало 90-ых) - может что и путаю.

Ну а в отношении заголовка badblk.sys - как бы ничего неординарного - с точки зрения ФС - он - достаточно обычный файл :) Так же как и скажем - indexf.sys :)

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

Попробую в следующие выходные добраться до первоисточника - и посмотреть - чего и как там. Ну или если вдруг время окажется - вечерами на неделе