PDA

Просмотр полной версии : Функционал TR-DOS



Vitamin
21.03.2007, 09:30
Перечитывал не так давно спектрумовские газеты/журналы и чуть ли не в каждом втором в статьях, посвященных TRDOS присутствуют жалобы на сокращенный функционал сей системы- типа это просто перенесенная на дискеты ленточная система.
И возникла у меня, в общем-то, до безобразия простая и понятная идея небольшого расширения возможностей сабжа безо всякой потери совместимости.
Имеется проблема удаленных файлов- они занимают ячейки в далеко не резиновой структуре каталога и занимают место на диске (тоже далеко не безграничное). Можно этот процесс соптимизировать- использовать для записи новых файлов место под удаленными. Это не приведет ни к какой потере совместимости или особо большим сложностям.
Имеем две операции, которые можно проделать с диском:
1) оптимизация каталога. Рядомлежащие удаленные записи в каталоге склеиваются в минимум записей (а-ля сателлиты), суммарная мнимая длина которых будет равна суммарной мнимой длине удаленных записей
2) запись файлов заранее известной длины (а в 99% так всегда) поверх удаленых файлов. Здесь, думаю, все ясно и понятно- добавляем запись в каталог, отрезаем от свободного места сколько заняли, возможно создаем новую запись (если "удаленная" запись одна). Возможно, придется делать еще раз оптимизацию.

Если каталог заполнен не сильно, то оптимизацию можно делать упрощенную- не сокращать число удаленных записей, но распределять размеры между ними- максимум первым и минимум (1 сектор) последним. Это создаст своеобразный пул свободных записей, которые можно быстро использовать для записи.

Думаю, такой функционал вполне можно поддержать (хотя бы опционально) в дисковых коммандерах или других программах. Кто что думает?

GriV
21.03.2007, 09:57
А чем с этой точки зрения DirSys не устраивает?

Vitamin
21.03.2007, 10:27
Ты бы еще спросил "а как ты относишься к популяции нигерийских тушканчиков".
DirSys никоим боком не относится к вопросу- про директории я ни слова не говорил, только про использование свободного места на диске. DirSys имеет отношение к этому такое же, как и к команде MOVE, ибо изменяется порядок записей в каталоге.

GriV
21.03.2007, 20:11
Ты просто подумай, а то любишь торопиться. DirSys относится прямым образом, поскольку позволяет некоторые косяки тырдоса обходить. С другой стороны, в ОСях пример был NKDOS там вообще использовался подход, который я сам в своё время планировал - каждый файл может быть одинаково файлом или каталогом (если имеет длину 8 секторов). В таком случае в нём можно хранить дополнительно ещё 128 файлов, т.о. можно безболезненно создавать сколько угодно файлов, т.к. уже в корне есть по меньшей мере 128 каталогов, и так далее плоди сколько хочешь.
Ты выставил две проблемы: мало файлов и нерациональное использование свободного места. Эти проблемы можно решить только изменением файловой структуры (смотри выше). Сам же тырдос никто переделывать не будет, практика показала что ничего хорошего с этого не выходит.

Vitamin
21.03.2007, 21:03
1) DirSys позволяет без большого геморроя обойти только один косяк трдоса- отсутствие каталоговой системы
2) Выставленные мною две проблемы можно если не решить, то облегчить (особенно вторую) предлагаемым способом (кстати никоим образом не переделывая трдос, это просто расширение функционала прикладных программ, никоим образом не затрагивающее ядро).

Evgeny Muchkin
22.03.2007, 09:44
Выставленные мною две проблемы
Ну я бы не говорил про проблемы ;) Наверное, правильнее сказать предложенные идеи :)

А вообще здравая мысль, почему бы и да, как говориться. :)

Grand
23.03.2007, 03:59
И возникла у меня, в общем-то, до безобразия простая и понятная идея... Имеется проблема удаленных файлов ... Можно этот процесс соптимизировать- использовать для записи новых файлов место под удаленными.Действительно, очень просто и логично. Такие же мысли приходили и мне в голову еще много лет назад. Жаль только, что ни в одной своей программе я еще не реализовал эту идею. Хотелось бы, чтобы другие кодеры воплотили это...

CityAceE
23.03.2007, 04:31
Жаль только, что ни в одной своей программе я еще не реализовал эту идею. Хотелось бы, чтобы другие кодеры воплотили это...
TRDN - хороший полигон для испытаний :)

Vitamin
23.03.2007, 09:44
TRDN - хороший полигон для испытаний
Ну дык и карты в руки :)
Имхо такой функционал нужен как раз коммандерам. Остальным приложениям он не особо нужен (но и не помешает). Если есть место в коде- можно и вставить.

CityAceE
23.03.2007, 10:09
Я это Grand'у и предлагаю. Правда там с местом для кода напряг жуткий.

Grand
26.03.2007, 01:22
Я это Grand'у и предлагаю. Правда там с местом для кода напряг жуткий.
Думал, конечно же думал над этим. Но прежде надо устранить еще оставшиеся недоделки в TRDN.

Rubts0FF
03.04.2007, 05:39
Поиски редактирования файлов любого размера навели на следующие мысли.
Какой же самый большой недостаток трдос'а? И в общем меня не устраивает только одно - максимальный размер файла.
Эти преславутые 255 секторов. Да, можно конечно и несколько файлов подряд записать, как это делает Zip или ZAsm при сохранении рамдиска, но подряд.

И решение есть, как кажется очень простое.
Э-х, если бы парни всей земли ...
В общем размер файла сделать 3-х байтным, т.е. размер в секторах считать старшим байтом размера файла. А для того что бы пзу трдос ничего не натворила, записать в идентификатор диска другое значение. Да и в пзу подправить не такая уж проблема.
И тогда ... в каждом файле хоть свою дисковую систему, КАЖДЫЙ СВОЮ. Требование одно копирование, уплотнение диска, удаление из расчета 3-х байтовой длинны файла. За внутреннее содержание файла ответственна программа создавшая его. Каждый использует как хочет или может. Я не против ковыряний внутри, просто разговору о формате таких файлов займет очень много ... ЛЕТ.

DirSys, кстати сказать, ни каких боков трдос не исправляет, позволяет организовать показ каталога, а ограничение в 128 файлов так и осталось.

Vitamin
03.04.2007, 07:19
В общем размер файла сделать 3-х байтным, т.е. размер в секторах считать старшим байтом размера файла. А для того что бы пзу трдос ничего не натворила, записать в идентификатор диска другое значение. Да и в пзу подправить не такая уж проблема.
Имхо гиблое дело. Переделки существующего софта (а особенно прошивок) никто делать не будет. Если уж и идентификатор другой, то можно вообще свой формат диска сделать- с фрагментацией и прочим. А это, звиняйте, уже другая файловая система. И крутите что хотите.

Grand
05.04.2007, 01:15
...Да, можно конечно и несколько файлов подряд записать, как это делает Zip или ZAsm при сохранении рамдиска, но подряд.Много лет назад я взял на вооружение другой способ, похожий на то как в TR-DOS записываются файлы прямого/последовательного доступа (напомню: там размер таких файлов по 8Kb, и распологаться они могут в любой последовательности).


DirSys, кстати сказать, ни каких боков трдос не исправляет...Вроде никто этого и не утверждал. DirSys - это просто надстройка, позволяющая организовывать каталоги..

GriV
14.04.2007, 10:31
1) оптимизация каталога. Рядомлежащие удаленные записи в каталоге склеиваются в минимум записей (а-ля сателлиты), суммарная мнимая длина которых будет равна суммарной мнимой длине удаленных записей
2) запись файлов заранее известной длины (а в 99% так всегда) поверх удаленых файлов. Здесь, думаю, все ясно и понятно- добавляем запись в каталог, отрезаем от свободного места сколько заняли, возможно создаем новую запись (если "удаленная" запись одна). Возможно, придется делать еще раз оптимизацию.

Я тут похоже не так тебя понял... Это уже всё есть. Генс у меня записывал файлы поверх, если они одно размера в секторах были (хотя могу и ошибаться). Склеивать пустые места, освобождая файловые индексы в каталоге - это конечно неплохо, но есть такое соображение. Эти места вообще то бронируются для того, чтобы потом эти файлы можно было восстановить. Конечно, я согласен что этим мало кто пользуется (по крайней мере я - ни разу не восстанавливал так файлы, хотя в тырдосе уже лет 10 сижу), но всё же...
И ещё, использование каких-либо реорганизаций уже стёртых файлов не есть хорошо, потому что там может и важная информация хранится (а вот это я использовал - вытаскивал кое что нужно, про что сам давно уже забыд).

Добавлено через 2 минуты

если бы парни всей земли ...
В общем размер файла сделать 3-х байтным

Не получится, потому что DirSys оставлял в принципе систему файлов в порядке, а вот такое изменение коснётся файловой системы капитально, а так как основная масса программеров (и я в том числе) работают с каталогами ТыРДОСа напрямую (читая секторы *16 номер файла и т.д.) то ничего хорошего такое нововведение не даст.

Grand
15.04.2007, 09:38
... использование каких-либо реорганизаций уже стёртых файлов не есть хорошо, потому что там может и важная информация хранится ...Надо, чтобы в программе была возможность отключения этой функции.
К примеру, в системе RT-11 (и аналогичных ей) (http://grands.land.ru/docs/blk_dev.htm) на ДВК-совместимых, новые файлы всегда записываются в подходящие пустые области (там это не отключаемо), и одновременно есть возможность восстановить стёртый файл, если на него ещё ничего не записалось.


Это уже всё есть. Генс у меня записывал файлы поверх, если они одно размера в секторах были (хотя могу и ошибаться).
Art Studio и мой GSV (тот, что не x.xDS) (http://grands.land.ru/creative.htm) пишут на диск новые картинки поверх старых. Но лично мне хочется, чтобы появились программы, записывающие файл на место удалённого файла, если он больше или равен новому файлу, а остаток
оформляли бы как следующий удалённый файл (при условии, конечно, что есть свободное место в каталоге).

Vitamin
15.04.2007, 17:35
Я тут похоже не так тебя понял... Это уже всё есть. Генс у меня записывал файлы поверх, если они одно размера в секторах были (хотя могу и ошибаться).
Перезаписывать файлы поверх оригинальных, если они одного размера, могут многие программы (часть моих в том числе, если не путаю). Про запись поверх _уже удаленных_ файлов я не слышал.
Плюс, как точно сказано:


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

А то, судя твоей логике, надо исключить из функционала команду Move;)

CityAceE
16.04.2007, 01:32
Как мне кажется, алгортим действий должен быть таким:
1. Смотрим включена ли функция. Если выключена, то действуем как обычно.
2. Смотрим на количество файлов в каталоге. Если их 128, то выходим.
3. Смотрим, есть ли удалённые файлы. Если нет, то действуем как обычно.
4. Ищем удалённые файлы и сравниваем их длину с записываемым файлом. Если есть удалённый файл равной длины, то новый файл пишем на его место, иначе пишем в файл с минимальной подходящей длиной.
5. Из оставшихся от удалённого файла секоторов создаём "новый" удалённый файл и корректируем каталог, записывая в него новый файл и новый удалённый файлы.

Sonic
16.04.2007, 09:23
Учтите что стандартная команда MOVE в TR-DOS корректно работает только в том случае, если файлы на диске расположены в том же порядке, в каком они указаны в каталоге. То бишь нельзя, например, файл дописать в хвост диска, а описатель его указать в начале каталога, на месте стертого файла.
Работает команда следующим образом: находим стертый файл, определяем его начало на диске, находим следующий нестертый файл, определяем его начало, копируем сектора нестертого файла "вверх" по диску (подтаскиваем его к началу), меняем местами описатели стертого и нестертого файла в каталоге, повторяем.
При нарушении условия непрерывности дискового пространства в результате такого MOVE получим кашу. Также можно получить неубирающуюся "дырку" на диске, если делаем следующее:
В каталоге:
Файл1
Файл2
На диске:
Файл1
<Свободное место>
Файл2
Даже если сотрем файл2 и сделаем MOVE, свободное место не уберется.
Другие реализации MOVE работают по-другому. Хотя сама по себе идея использования "дырок" хороша.
Кстати еще я бы убрал файлы произвольного доступа (ими так никто и не воспользовался), а для последовательного доступа сделал бы возможность открывать любой файл (а не только "#"). Потоковый ввод/вывод - вещь полезная. Можно писать/читать файл по частям не заботясь о его длине. Все прочие дисковые ОС на Спеке и даже ОС Микродрайва это умеют.

CityAceE
16.04.2007, 09:25
стандартная команда MOVE в TR-DOS
Не уверен, что кто-то ею пользуется... Хотя, безусловно, скидывать её со счетов нельзя.

Grand
17.04.2007, 01:42
5. Из оставшихся от удалённого файла секоторов создаём "новый" удалённый файл и корректируем каталог, записывая в него новый файл и новый удалённый файлы.Именно такой алгоритм.
Я бы добавил ещё в последний пункт, что
имя "нового" удалённого файла надо делать какое-нибудь "отвлеченное": что-то вроде "unused" (с первым символом #01, естественно), чтобы у пользователя не было искушения попытаться его восстановить. :)


А то, судя твоей логике, надо исключить из функционала команду Move ;)Ну, совсем от MOVE не избавиться (мой опыт работы в RT-11 свидетельствует (там эта команда называется SQUEEZE)), а вот, что применять ее придется уже не часто, - это факт.

Sonic
17.04.2007, 10:08
Не уверен, что кто-то ею пользуется... Хотя, безусловно, скидывать её со счетов нельзя.

Ей не пользуются потому что она до безобразия медленная ибо использует в качестве буфера только рабочую область бейсика, которая резервируется по MAKE_BC_SPACES (кажется это какой-то RST, не помню). Соответственно буфер получается крохотного размера. Вот если бы эта штука умела использовать верхнюю память, да еще и алгоритм оптимизировать...
А что касается ее наличия как таковой - Commander'ы это хорошо, но командная строка должна быть. Вдруг нету Commander'а...
И еще бы к ней индикатор прогресса добавить, как у форматирования в 5.04T. Сразу менее скучно становится.

Grand
18.04.2007, 01:25
При нарушении условия непрерывности дискового пространства в результате такого MOVE получим кашу. Также можно получить неубирающуюся "дырку" на диске, ...Всё нужно учесть. Если каталог будет правильно скорректирован (пункт 5 в алгоритме CityAceE), то и проблем никаких не будет.