ImageUtils

[Hunta]

Для информации

Это уже всё раскопано - есть в документации или исходниках

в 6 блоке

Такое впечатление, что не всегда 6 блок является первым блоком сегмента каталога. Что-то где-то мне такое попадалось, но давно и на что намекает
а) наличия поля - первый блок каталога в Home блоке и
б) наличие проверки и ПРЕДУПРЕЖДЕНИЯ в ImageUtils. Не помню - я это дописал или скопировал(переделал) их TU58fs..

Надо будет поставить пометку в памяти - провентилировать этот вопрос

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

Первые два - как минимум из исходников DUP v5.07

[Hunta]

если размер Extra Bytes достаточно (??) большой - что-то не так в создании каталога.

Уточнение - не "когда Extra Bytes достаточно (??) большой", а когда нужно больше, чем один сегмент - смещение до поля, где будет установлен флаг "End Of Segment", вычисляется сейчас неправильно.
Работаю.
Заодно был рефакторинг по более простому созданию и работе с полями, которые а ля массив - как сами сегменты каталога и записи о файлах в сегментах. Что приводит к необходимости нового тестирования

[Hunta]

В первом приближении всё работает

Образ диска для теста был создан ImageUtils и вполне нормально воспринят в RT-11

.DIR RK5:
 21-Jan-2024
CHART .DOC    18  27-Jul-1988    CHART .SAV    47  13-Mar-1988
COLRDB.SAV    42  17-Mar-1988    CRERDB.SAV    27  17-Mar-1988
EDDOC .DOC    37  28-Jul-1988    EDDOC .SAV    57  17-Mar-1988
EDIMEN.SAV    56  13-Mar-1988    EDRDB .SAV    62  17-Mar-1988
GENRDB.DOC    25  28-Jul-1988    GENRDB.SAV    67  13-Mar-1988
INTMEN.SAV    20  13-Mar-1988    INTRDB.DOC    23  07-Jun-1991
INTRDB.SAV    91  13-Mar-1988    MENU  .DOC    78  28-Jul-1988
MENU1 .TXT    30  01-Feb-1988    MENU2 .TXT    37  01-Feb-1988
MERRDB.SAV    38  17-Mar-1988    PRIMEN.SAV    18  13-Mar-1988
RDBEK .DOC    47  27-Jul-1988    RDBEK1.TXT    65  26-Feb-1988
RDBPR .DOC    61  03-Dec-1987    RETRDB.SAV   111  17-Mar-1988
SORRDB.SAV    37  17-Mar-1988    UNIRDB.SAV    26  17-Mar-1988
 24 Files, 1120 Blocks
 3656 Free blocks

.TYP RK5:CHART.DOC
TEST!!!!!!!!!!!!!!!!!!!!!!!!.TOC
.STL
.TTL

relqcionnaq subd dlq mikro-|wm
paket grafi~eskogo predstawleniq
informacii iz bazy dannyh subd-mikro


^O

.DUMP/TERM/RAD/WORD RK5:/START:6/END:7


RK5:/S:6/E:7
BLOCK NUMBER  000006
000/ 000011 000002 000002 000044 000030 002020 012001 071640 *......$....... s*
       I      B      B      6      X     Z     CHA    RT
020/ 015533 000022 000000 017560 062564 072163 035040 024451 *[.....p.test :))*
     DOC      R           EAH    PIL    RYK    IL     FWQ
040/ 072040 071545 020164 024472 020051 062564 072163 035040 * test :)) test :*
     RWH    RRU    EG.    FW4    EE3    PIL    RYK    IL
060/ 024451 072040 071545 020164 024472 020051 002000 012001 *)) test :)) ....*
     FWQ    RWH    RRU    EG.    FW4    EE3     YX    CHA
100/ 071640 073376 000057 000000 006660 000000 000000 000000 * s~v/...0.......*
     RT     SAV     AG           BGX
120/ 000000 000000 000000 000000 000000 000000 000000 000000 *................*

140/ 000000 000000 000000 000000 000000 000000 000000 002000 *................*
                                                       YX
160/ 0124^O

.

В CHART.DOC есть префикс блок (один) и выделенный жирным текст вывода команды TYPE из него, а так же Extra Bytes в записи каталога (выделенно жирным в дампе первого блока первого сегмента каталога
Как я уже писал ранее, PIP не принимает во внимание префикс-блоки, а эксперимент с KED показал, что и он тоже...

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

Ха! Только что нашёл ещё один косяк

.DIR/FULL/SUMM RK5:
 21-Jan-2024

    20 Files in segment 1

< UNUSED >  1828                 < UNUSED >  1828
     4 Files in segment 2

     9 Available segments, 2 in use

 24 Files, 1120 Blocks
 3656 Free blocks

.

При создании образа в исходном коде TU58fs резервируются 3 (три!) записи в сегменте каталога (получатся - в конце), что бы в первом из них можно было оставить запись о конце сегмента. Как я понимаю, автор так решил проблему, когда при делении (размера сегмента (1024 байт) минус заголовок сегмента (10 байт) - итого 1014 байт) на размер записи о файле даёт целое количество элементов каталога. Скажем, если размер Extra Bytes - 12 байт плюс размер стандартной информации 14 байт даёт размер записи о каталоге - 26 байт. Что даёт ТОЧНО 39 записей о файлах. Но, по правилам, последней записью в сегменте должна быть запись "End Of Segment". И, видимо, что бы не усложнять логику вычисления - в какую запись каталога в каком сегменте попадёт очередной файл (что бы ненароком не занять последнюю запись) - автор и уменьшил вычисленное количество записей на три.

Я пошёл другим путём У меня резервируется одно слово для записи "End Of Segment", это учитывается при вычислении количества записей о файлах в сегмента и всё настроено так, что это слово будет СРАЗУ после записей о файлах. Но уменьшение на 3 - всё ещё есть в моём коде Теперь это точно уберу

Не уверен, что это правильный вариант - надо будет глянуть - как поведёт себя в аналогичной ситуации RT-11

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

Эксперимент показал три вещи:
- RT-11 не резервирует полную запись о файле (вместе с Extra Bytes) в конце сегмента - в моем случае за End Of Segment шло 6 слов, то есть это была - или стандартная запись (7 слов) с флагом End Of Segment - или End Of Segment сразу за последней записью о файле полного (то есть с Extra Bytes) размера.
- PIP копирует Extra Bytes
- В PIP, похоже, есть ошибка - он не очищает буфер Extra Bytes, так как после копирования нескольких (24) файлов, первый из которых содержал в Extra Bytes не нули - копия их содержимого появилась у ВСЕХ файлов Надо будет глянуть исходники PIP

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

Нашёл подсказку - "Note that an end-of-segment marker can appear as the last word of a segment. It does not have to be followed by a name, file type, or other entry information." - то есть мой подход - ОК!

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

А вот фигвам... Автор TU58fs был прав:
"If you use no extra words, each segment can contain 72(10) entries. However, the maximum number of entries includes three that are reserved by the operating system and not available to the user. These three entries in each segment are for end-of-segment, empty (but reserved), and a reserved entry for use when creating a tentative file. Therefore, the maximum number of usable entries per directory segment is 69(10)."
Ок, буду править

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

Хм.. Править... Вот только после SQUEEZE я таких трёх резервных элементов не вижу... В общем, думать и смотреть исходники DUP. Пока оставлю свой вариант без резервных элементов..

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

Ха! Extra Bytes разможает не только PIP, но и SQUEEZE (то есть - DUP)

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

И ещё ошибка - PIP не сохраняет флаг наличия у файла Prefix блоков..

[Hunta]

Из занимательного (из DUP)

    //DK.RX1	== 700			;Offset to RT/RSX word 1
    //  GOD$ID== -1			;If DW, disk is V5.3 structure
    //  BAD$ID== -2			;If DW, disk is corrupted
    //; RTE$ID==^RRTE			;RTEM initialized disk (by JOAT)
    //DK.RX2	== 702			;Offset to RT/RSX word 2

По описанию структуры home блока, смещение 700 содержит "Block number of first data block (0)"
Но в случае (хорошего) DW там будет -1
А смещение 702 для RTEM систем будет содержать ^RRTE

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

Если я правильно понял увиденное в USR, то это правило трех резервных записях в конце сегмента каталога должно звучать примерно так - при создании нового файла если запись для создания попадает в одну из последних трёх записей в сегменте - будет перенос записей между сегментами. Как-то так. И как показали эксперименты - RT-11 нормально воспринимает сегменты, где есть информация о файлах в этих последних трёх записях.

Так что пока не заморачиваюсь на этот нюанс - до налетания на реальную ошибку со стороны RT-11

[Hunta]

Проверил после всех переделок (под RT-11) распаковку тома RSX. Одна ошибка и одна неточность. Неплохо

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

Проверил распаковку образа от DOS-11. Всё ок
XXDP позже проверю, но по идее - там тоже должно быть всё ок - так как эта её ФС основана на ФС от DOS-11 - и в коде тоже

[Hunta]

ImageUtils

Если по прежнему есть интерес - могу отдать попробовать. Тесты дошли до состояния, когда я готов отдать программу во внешнее тестирование. Аналога SQUEEZE по прежнему нет, но можно распаковать-запаковать образ (и получить тот же эффект) или в принципе создавать образ командным файлам по потребности

[form]

А время создания файла будет (в RT-11 фс)?
Если что, там в поле номера задачи/канала пишется время 3-секундных единицах.

[Hunta]

А время создания файла будет (в RT-11 фс)?

Сейчас нет, но есть мысли добавить

там в поле номера задачи/канала пишется время 3-секундных единицах

А оно точно в RT-11 пишется? Или только в TSX?

[form]

А оно точно в RT-11 пишется? Или только в TSX?

Реализовано только в TSX.
В RT-11 source kit в SYSTEM.MAC (исходники одноименного MLB) для file entry определяется E.TIME (.MACRO .DIEDF) и в описании форматов данных упоминается:

;       +-------+-------+
;E.TIME:|               |[12] file closing time <fut>
;       +-------+-------+

Еще вроде в описании форматов дисков/файлов упоминается, что значение слова после закрытия нового файла зарезервировано на будущее.

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

А для file stat word там вообще понафигачено на будущее:

        .BS     E.BLU           ;blue file code<fut>
        .BS     E.GRN           ;green file code<fut>
        .BS     E.RED           ;red file code<fut>
        .BS     E.CUST          ;customer defined colors<fut>
        .BS     E.PRE           ;file contains prefix block(s)<fut>
        .BS     E.TEXT          ;file is displayable on ANSI terminal<fut>
        .BS     E.ARCH          ;file has been archived<fut>
        .BS     E.XTRA          ;extension status word in first extra word<fut>
        .BS     E.TENT          ;tentative entry
        .BS     E.MPTY          ;empty entry
        .BS     E.PERM          ;permanent entry
        .BS     E.EOS           ;end of segment
        .BS     E.FIX           ;non-movable file<fut>
        .BS     E.HIGH          ;move high on squeeze<fut>
        .BS     E.READ          ;read-only
        .BS     E.PROT          ;protected file

[Hunta]

В RT-11 source kit в SYSTEM.MAC

Это я в курсе - описание объектов в ImageUtils строится на информации из этого файла.

после закрытия нового файла зарезервировано на будущее.

Да и это знаю.

Реализовано только в TSX.

Вот по всем этим причинам пока и не реализовано. Но технически не сложно.

Ещё в планах (это уже в ближайших) - добавить в слово даты эпоху, а то пока только до 1999 года

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

А для file stat word там вообще понафигачено на будущее:

Это тоже всё знаю и эти все флаги уже расписаны.