-
Обнаружил некоторые ненужные действия в процессе распаковки образов :) Поправил :)
Теперь работа программы ускорилась практически в два раза :)
На тестовом наборе (разные операции, в основном распаковка, но прилично и работы с секциями) примерно в 7.5 гигов время работы было примерно 40 минут, теперь в районе 21 минуты.
-
Продолжаю доработку вывода тех информации. Что бы и всю и читабельно :)
К сожалению, выходные закончились, так что дальше всё будет медленней.. До следующих выходных :)
-
Что такое кластерный АД? Это файловая система RSTS :)
По порядку.
Достаточно быстро разрабы RSTS дошли до точки, когда выяснилось, что 16-ти битный номер блока - это мало :) И с этим надо что-то делать :)
Вспоминая другие ФС, можно увидеть три варианта - забили, с самого начала использовли больше 16-ти бит (RSX), ввели понятие секции (RT-11)
В RSTS народ пошёл своим (не оригинальным) путём - ввёл понятие кластера.
То есть, в зависимости от размера диска, вычсиляется размер кластера, так что бы номер блока оставался 16-ти битным - и вуаля. Этот размер кластера (устройства) иногда даже записывается в секретное место :)
А вот дальше начинается АД.
Помимо размера кластера для устройства - ввели ещё размер кластера для pack-а (а ля disk pack, а ля дисковый пакет). Типо - умолчание для всего файлового на диске. Тоже записан в метаинформации.
Но.
Если надо - для каталога можно ввести свой размер кластера по умолчанию - для всех файлов в этом каталоге.
И.
Если очень надо - для файла можно ввести свой размер кластера - конкретно для этого файла.
Да уж.. Гулять так гулять :)
На текущий момент - метаинформация обрабатывается вроде корректно и файлы извлекаются вроде тоже корректно.
Но вот техническая информаци, а конкретно - что в каком блоке что находится... Воюю :)
-
Тэкс.. вроде то, что я вижу в тех информации о записях в MFD и UFD и их распределении по блокам - меня устраивает :) Двигаемся дальше :)
-
Как обычно - параллельно добавлению функционала - идёт доработка внутренностей и устранение старых "проблем".
С самого начала ImageUtils писался так, что бы не гонять лишний раз данные из образа туда-сюда. Скажем, если файл в образе занимает смежные блоки (непрерывный), то вместо создания для объекта файл массива с данными файла и копирования байт в него - ImageUtils создаёт объект SmartArray - который выглядит как массив, но на самом деле просто ссылается в основной массив с данными из образа.
Всё это хорошо работает, когда файлы (или другие данные из образа) непрерывные, но ... Это технически - редкий случай. И для НЕнепрерывных файлов всё делается по старинке. Вот это я и пытаюсь исправить - пока при работе с ФС RDS.
Движение вперёд есть, но пока ещё не всё работает. Тестирую, исправляю ошибки, доработатываю, тестирую,...
-
Упрощение структуры SmartArray. Проверено на наборе старых тестов и на работе с ФС RSTS.
На этом пока приостановлюсь - надо кое-что оценить и подумать - как двигаться дальше во внутренних доработках.
А пока вернусь к недоделанному в ФС RSTS
-
Тесты по RSTS включил в общий список
-
С ФС RSTS вроде более менее закончил. Последние доработки - дамп метаинформации.
Дальше в планах - возможно, как обычно - рефакторинг кода и затем - разные вариант ФС RSTS на лентах.
-
Хе :) Недореализованный функционал - тесты споткнулись :) Так что сначала его, а уже потом - то, что выше :)
-
Функционал допилил, все тесты (включая с ФС RSTS) прошли - очередной коммит.
И тут я налетел (в очередной раз) на ленту BRU с ошибками (переставлены местами блоки), так что малость поразвлекаюсь с новой программой (там крайне ранняя пред-альфа версия) - ImagesEditor :)