ODS1 FILES-11 DECFILES11A reader

[AFZ]

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

В топку TC!

FAR рулит!

[Advertiser]

[Denkixot]

В топку TC!

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

[anasana]

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

[anasana]

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

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

оказалось имеет смысл добавить режим не перезаписывать файлы поверх с одинаковыми именами, т.к. текстовый редактор меняет имена файлов в описаниях директорий, а в информации о файле у всех всё так и остается имя "zzredakof.sys".
В образе их оказалось больше сотни разных по содержимому. (для этого надо убрать галочку Overwrite)

[Hunta]

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

[anasana]

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

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

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

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

[anasana]

Причёсывая извлекалку добрался до рефакторинга вывода списка "плохих" блоков на томе, ну и реальный дамп у себя отыскал у которого "не всё чисто", подходящий для тестов.
В мануале 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

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

[Hunta]

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

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

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

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

[form]

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

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

[form]

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

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