-
Столкнувшись с проблемой редактирования интерлейсных образов и не обнаружив под рукой удобного инструмента для де-интерлейсинга и интерлейсинга - добавил этот функционал в прогу. Учитывая, что много нужного в программе уже было - хватило на набивку кода и отладку примерно получаса в обед.
Пока проверено только на одном DX образе, но, учитывая, как оно делается - вроде должно работать по любому.
Ну и - программа НЕ ПРОВЕРЯЕТ - чего вы ей подсунули, она тупо смотрит на параметры и делает работу по принципу - Вы это хотите - нате! То есть вполне можно взять на вход образ, который не RX01, сказать, что он RX01 и попросить загнать в образ RX02 :) Ну.. Сами виноваты :)
-
Ну и ещё одна доработка. При наличии, конечно, соотвествующего файла :)
Код:
Physical block N 26 -> 0:$PrimaryBootloader
Physical block N 27 -> 0:$SecondaryBootloader
Physical block N 28 -> 0:$PrimaryBootloader
.......
Physical block N 42 -> 0:$SecondaryBootloader
Physical block N 43 -> 0:$SecondaryBootloader
Physical block N 44 -> 0:$SecondaryBootloader
Physical block N 45 -> 0:$SecondaryBootloader
Physical block N 47 -> 0:$SecondaryBootloader
Physical block N 49 -> 0:$Directory
.....
Physical block N 1663 -> 0:FDF333.DOC
Physical block N 1664 -> 0:FDF333.DOC !! bad block !! 64 0 1
Physical block N 1665 -> 0:FDF333.DOC
.....
Physical block N 1738 -> 0:FDF333.DOC
Physical block N 1740 -> 0:FDF333.DOC
Physical block N 1976 -> 0:FILE.BAD
Physical block N 1996 -> 0:FILE.BAD !! bad block !! 76 0 21
Physical block N 1998 -> 0:FILE.BAD
Physical block N 2000 -> 0:FILE.BAD
-
Последствия моего исправления руками битого образа и внешнего тестирования - найден сценарий, до которого я не додумался и не наткнулся - дубли файлов по именам. Доработка работы с дублями ведётся.
И будёт ешё одна доработка - восстановление И удалённых файлов. Скорее всего - в подкаталог типа LostAndFound
-
Первая прикидка нового
Код:
[2022-нояб.-08 22:09:51 Warning] File with same name 'EEXEEX.EEX' found - saved as 'EEXEEX.EEX.2'
PRM1 .MAC 3 11-OCT-1984 ZAP .MAC 1 02-OCT-1984
CTS .MAC 1 02-OCT-1984 CFR .MAC 1 02-OCT-1984
PZU3 .OBJ 1 19-JUL-1984 FILE01.BAD 1 01-JAN-1972
OZU .OBJ 2 07-JUN-1984 SPG .MAC 3 18-OCT-1984
PRD3 .MAC 3 11-OCT-1984 RED .MAC 2 17-OCT-1984
FOR .MAC 2 21-JUN-1984 PRM3 .MAC 3 11-OCT-1984
VZU .MAC 4 03-JUL-1984 RASPC .MAC 2 26-OCT-1984
SMK .BAK 1D 25-OCT-1984 ZPS .MAC 2 20-JUN-1984
RZU .MAC 3 19-NOV-1984 IZSL .MAC 4 14-JUN-1984
RASP .MAC 2 17-OCT-1984 TEXT5 .BAK 5 25-OCT-1984
FILE02.BAD 1 01-JAN-1972 IZKL .MAC 5 19-JUL-1984
PRD3 .MAC 4D 11-OCT-1984 ZPRM .MAC 3 13-JUN-1984
UDL .BAK 1D 20-SEP-1984 SPT .MAC 2 29-JUN-1984
NUM .MAC 2 13-JUN-1984 SPT .OBJ 1D 19-JUN-1984
FILE04.BAD 1 01-JAN-1972 TYP .MAC 2 13-JUN-1984
UDL1 .MAC 8D 26-OCT-1984 IZM .MAC 3 02-JUL-1984
DATA .MAC 5 20-JUN-1984 TEXT5 .MAC 5 30-OCT-1984
SPM .MAC 3 31-MAY-1984 RUVD .MAC 10D 10-OCT-1984
PRD2 .MAC 3 11-OCT-1984 IZSL .MAC 4D 14-JUN-1984
PRM2 .MAC 3 11-OCT-1984 PRD1 .MAC 3 11-OCT-1984
DATA .MAC 1D 20-JUN-1984 SBOR .MAC 25 17-JUL-1984
SPM .MAC 3D 31-MAY-1984 WZU .MAC 4 23-MAY-1984
SBOR .MAC 7D 17-JUL-1984 TEXT1 .MAC 8 12-JUN-1984
WKL .MAC 22 09-JUL-1984 RZU .MAC 3D 15-OCT-1984
TEXT4 .MAC 11 18-OCT-1984 TEXT5 .MAC 5D 30-OCT-1984
SMK .MAC 3 26-OCT-1984 UDL .MAC 8 30-OCT-1984
UDL .MAP 5D 26-OCT-1984 VVTO .MAC 9 17-OCT-1984
FILE03.BAD 1 01-JAN-1972 TVZU .MAC 13 23-MAY-1984
TKON .MAC 14 10-OCT-1984 RUVD .MAC 10 13-NOV-1984
TEXT2 .MAC 11D 18-OCT-1984 PSM .MAC 4 26-OCT-1984
SBORM .MAC 9D 11-OCT-1984 FILE05.BAD 4 01-JAN-1972
TEXT3 .MAC 16 17-OCT-1984 SBORM .MAC 26 22-OCT-1984
UDL1 .OBJ 10D 26-OCT-1984 TEXT2 .MAC 13 18-OCT-1984
GENER .MAC 15 12-OCT-1984 IZKN .MAC 11 11-OCT-1984
PSM .OBJ 10D 26-OCT-1984 FILE06.BAD 5 01-JAN-1972
GENER .MAC 17D 12-OCT-1984 FILE07.BAD 1 01-JAN-1972
EEXEEX.EEX 8D 01-AUG-1972 FILE08.BAD 1 01-JAN-1972
EEXEEX.EEX 6D 01-AUG-1972 FILE09.BAD 32 01-JAN-1972
IZKN .MAC 14D 11-OCT-1984
77 files, 342 blocks
138 Free blocks
-
Очередная доработка по более правильному поведению программы в случае ошибок в образе - для образов с RT-11.
Для тех, кто использует ImageUtils - по присланной вам ссылке выложена обновлённая версия - но она пока без особо-интенсивного тестирования. В тепличных условиях работает, в случае ошибок - сообщения о них приветствуются :)
-
Не совсем про доработку ImageUtils, скорей - интересный вариант работы, когда нужно иметь прозрачную связь между массивами.
Скажем, есть образ диска RT-11. Там есть home block (блок с номером 1). Допустим, хочу я его проинить - соотвественно, мне надо проинитить элементы массива со смещением (пусть массив байтовый) от 512 до 1023. А ещё есть сегменты каталога - много - со смещениями [6*512..8*512-1], [8*512..10*512-1] и так далее.. И каждый раз надо эти смещения считать.
Но в восьмой версии C# появились диапазоны (range) и можно выпилить кусок из массива, написав что то типа homeBlock = image[512..1023] и поразвлекаться с homeBlock, используя уже более простой индекс - от 0 до 511. Удобно? Да. Но есть нюанс. Это будет работа не с куском из шmage, а со вполне самостоятельным экземпляром массива, то есть, по сути - image[512..1023] - всего лишь удобный способ вызвать Array.Copy(), в нашем случае - что-то типа
Код:
homeBlock = new byte[512];
Array.Copy(image, 512, HomeBlock, 0, 512)
О да, не спорю - пришлось набить ГОРАЗДО МЕНЬШЕ символов, а реальный код, напоминающий вышенаписанное - сгенерит компилятор (традиционное название подхода - синтаксический сахар и его сейчас в C# - МНОГО :) ).
Но что если я хочу проинить HomeBlock? А потом записать Image в файл? Упс.. Придётся скопировать HomeBlock обратно в Image и вспомнить про смещения. Не.. Не сильно легче и удобно :)
И таких моментов у меня в ImageUtils накопилось.. Много :) Идея появилась с примерно неделю назад, примерно со среды (вечера, плюс момент засыпания) крутилась в голове и вот сегодня я набросал код :) SmartArray :) Теперь можно написать примерно так:
Код:
SmartArray<byte> image = new SmartArray<byte>(65536);
SmartArray<byte> homeBlock = image[512..1023];
homeBlock[0] = 10;
homeBlock[1] = 12;
И записываемые значения 10 и 12 попадут куда надо - в элементы 512 и 513 массива image. Этакий эквивалент (для знатоков) оператора EQUIVALENCE в FORTRAN-е :)
А теперь хочу попробовать обойтись без методов работы с image на уровне блоков (помним же, что это образ диска, а на диске блоки, да ещё и бывают физические и логические, да ещё и интерлейс.. ) - аж два набора методов для чтения-записи. Брррр :)
И вот видется мне подход, когда на считанный image я кладу два отображения - физические блоки и логические, плюс указываю методо подсчёта интерлейса для физических блоков... Что то типа (пока это фантазия :) )
Код:
SmartArray<byte> image = new SmartArray<byte>(65536);
SmartArray<byte>[] logical = image[,, 512];
SmartArray<byte>[] physical = image[,, 128];
И писать что то типа logical[1][0] = 10 :) попадая как раз в home block (логический блок 1, физические блоки 36-38-39-40, смещения 4608..4735, 4864..4991 ну и так далее :)
Ну и начала крутиться в голове похожая идея, только более сложная - для DisAsm-а, поскольку там в LDA, SAV, TSK и им подобным файлам куча служебки, а уж в OBJ её на порядок больше, плюс команды бывают одно, двух, трёх, четырёх и пятисловные.. :) Но там её ещё надо, засыпая, покрутить :)
Пока попробую для ImageUtils (и TU58fs) :)
- - - Добавлено - - -
Засада подкралась оттуда, откуда не ждали :D range - он только int, то есть максимальный размер образа - 2 Гб :) Ну, если сделать блочный режим - тогда в принципе норм :) 1 ТБ - что перекрывает максимальный размер диска или раздела для ODS-1. Но с образами от VMS могут быть проблемы... :)
-
Перепилил ImageUtils на использование SmartArray<byte> вместо byte[].
Пока код был изменён в лоб, никаких плюсов от SmartArray<byte> использовано не было.
Попутно исправил несколько ошибок, которые проявились бы в специфических сценариях, но могли проявится.
И код, который был написан для обнаружения и сохранения дубликатов в ФС RT-11, неожиданно выстрелил в ODS-1 - оказалось, не совсем корректно был написан код, который сохранял файл в нескольких вариантах - прицел был на текстовые файлы. Помню, бродили тогда некоторые мысли - но уже не помню, до чего я тогда додумался и по любому - код был написан некорректно. Подумал, поправил в лоб, потом ещё подумаю.
Думаю порезвится с использованием новых возможностей на модуле работы с ФС RT-11 - она весьма простая, но большая часть кода получена в наследование и не использовался даже подход с описанием структуры ФС в виде классов с аттрибутами - как я сделал для ODS-1. Хотел давно переделать - вот и удобный случай :)
Но сначала посплю :)
-
Рефакторинг. Спрямление и сокращение кода с новым подходом к массивам :)
Сообразил, что из-за физических блоков с интерливом так же удобно работать с блоками, как с байтами без наличия внутренней поддержки не получится. Так что с наскоку не получилось. Думаю...
-
Модуль работы с образом на блочном уровне. Было 376, стало 215 строк - весь код работы с физическими блоками (включая интерлейс) перенесён на более низкий уровень. И методы стали гораздо проще :)
Теперь постепенное избавление от использоваия как результата byte[] и переход на SmartArray :)
-
Как было
Код:
stream.Data = new RADImage((ImageData.BlkGetBlocks(start, blkCount)))
При этом метод BlkGetBlocks создавал байтовый массив нужного размера, в который копировал содержмое соответствующих блоков образа. Думаю, понятно, что если изменить какой то байт в stream.Data, то, что бы это появилось в образе диска - нужно скопировать обратно.
Как стало
Код:
stream.Data = ImageData[start..(start+blkCount)];
Первое. Вообще никакого копирования :) В принципе! :)
И второе - если что то изменить в stream.Data - оно (волшебным образом :D ) материализуется в ImageData :)
- - - Добавлено - - -
А теперь работает и обратно
Код:
ImageData[start..(start + blkCount)] = stream.Data;
Но, конечно, если stream.Data создана на основе ImageData, то операция как лишена всякого смысла :)
