Новая система каталогов в TR-DOS

[Spectre]

Ну не скажи, единственный...
1. Не все пользуются RC и QC. Я думаю, что больше пользователей пользуются FAR'ом.

Я меньше всего беспокоюсь за pc'шные утилиты (FAR, Total Commander, SN, AY_Emul...), в них добавить поддержку любой системы каталогов - это дело нескольких часов. Добавить же аналогичную систему в спектрумские утилиты - дело нескольких дней, а иногда практически невозможно.

Те кто не пользуются этим двумя коммандерами вместо каталогов увидят файлы-пустышки. Удобно? Нет!

Я думаю здесь возможна "частичная поддержка" системы каталогов. Это когда программа просто будет при выводе каталога диска пропускать директории (детектятся по #00 00 01 в дескрипторе).

2. Как и в случае с DirSys сортировка файлов по каталогам убьётся, если сделать MOVE самой системой TR-DOS или коммандером, который ничего не знает про каталоги.

К сожалению любая придуманная система каталогов тяжело переживет Move из TR-DOS или другой программы ее не поддерживающей. Это основная причина почему я с Павлом предлагаем новую систему: тогда есть возможность с наименьшими проблемами переделать старые утилиты под поддержку каталогов.

Приведу пример: В Alasm 4.47 AlCo добавил комманду Move. Чтобы она не портила структуру существующих каталогов нужно научить Alasm пересчитать таблицу ссылок. В случае DirSys'а потребуется изыскать дополнительных 512(1280) байт в памяти для хранения структуры каталогов, найти место для громоздкой процедуры рассчета CRC. В случае каталогов в отдельном файле опять-таки нужно найти место в памяти для его загрузки. В случае TRDIR дополнительного места не потребуется, то есть интегрировать ее проще всего.

3. Опять же есть софт который в системном секторе хранит свою информацию, соответственно погубит предлагаемую систему.

В системном секторе еще остается достаточно места для других программ. Можно переназначить их в свободное место. И такое использование достаточно редкое.

Это я к тому, что нереально сделать идеальную систему каталогов поверх TR-DOS. Недостатки все равно будут. Нужно лишь определить какие из недостатков являются наименьшим злом.

Уже обозначились 3 разных подхода к хранению структуры каталогов:

1) В 9-15 секторах 0-ой дорожки
2) В отдельном файле
3) В 0-8 секторах 0-ой дорожки вместе с файлами.

Первые 2 варианта безупречны с точки зрения теории:

я искренне считаю, что DirSys с высказанными мною дополнениями и есть самое то на мой взгляд система каталогов должна быть такой:
1. Не создавать никаких ограничений существующей файловой системе TR-DOS, то есть она не должна отнимать у TR-DOS ни одного сектора, ни одного файла и т.д.
2. Система каталогов должна быть абсолютно невидимой для софта, который ничего про неё не знает.
3. Файлы, находящиеся в каталогах должны быть видимы в софте, который ничего не знает про систему каталогов.
4. Запись, удаление, переименование и т.д. в коммандерах, не знающих о каталогах не должны гробить систему каталогов.

То есть если коммандер знает о каталогах, то он их видит и поддерживает, а во всех остальных случаях каталогов видно не должно быть. Они должны сидеть тихо и не портится

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

Суть в другом! Ты думаешь о том, каким бы образом запихнуть каталоги в программы, которые отродясь не думали о них. И получается, что это дело идет в ущерб юзеру. Ведь юзера мало волнует что в коммандере места мало - ему нужно удобство.

Абсолютно не согласен. Что может быть хуже для пользователя чем отказ от старых, проверенных временем утилит только потому, что они могут накрыть ему директории на диске? Он скорее не будет пользоваться директориями (что мы сейчас и наблюдаем, хотя 2 стандарта есть). Плюс идет жесткая привязка к определенному дисковому коммандеру: хотите сделать Move или Copy? Делайте его только в xxx коммандере!

Возвращаясь к тому с чего начали: давайте придумаем систему каталогов которую всем одинаково удобно интегрировать в свои (и чужие программы! DirSys в нынешнем виде, к сожалению, на это не тянет.

А вот эта идея мне понравилась, надо будет использовать:

А вот поддержать запись из коммандеров реально. Поясняю на примере DirSys:
1. У меня есть таблица принадлежности к каталогам всех 128 файлов, то есть даже тех файлов которые еще не существуют.
2. Если перед запуском, скажем, Alasm'а заполнить содержимое ячеек не существующих файлов принадлежностью, например, к каталогу SOURCES, то любой записанный на диск файл окажется в нужном нам каталоге. Или, например, перед запуском программы можно заполнять указанную область номером текущего каталога, таким образом запущенная, например, ArtSudio будет выгружать картинки в каталог где живет сама ArtStudio.

[CityAceE]

Не буду тебя цитировать, а то потом никому читать не удобно. Лишь подытожу
1. Все что лежит за гранью первых 9 секторов ты не приемлешь из соображений невозможности найти места в существующем софте, пусть даже это будут всего 512 байт.
2. Вариант с MagicNumber поддержан.
3. Вариант с записью в таблицу принадлежности, чтобы файлы оказались в нужном месте, поддержан.

Напрягаю свою мозговую извилину и рожаю вот такой вариант:

1. Суммарное число файлов и каталогов не может превышать какого-то максимума Это количество зависит от формата хранения имени каталога и соотношения количества файлов и каталогов на диске (см. ниже).
2. Таблицу (длинной N байт) принадлежности файлов к каталогам и каталогов к каталогам держать в 9-м системном секторе. Там же держать дескриптор системы и контрольную сумму и др. необходимую информацию.
4. Названия каталогов хранить в первых 9-ти секторах системной дорожки, при этом хранить их начиная с конца 8-го сектора и далее вниз. То есть файлы растут снизу вверх, а каталоги сверху вниз пока где-то они не встретятся Необходимо помнить, что список файлов закачивается нулем, а каталоги тоже нужно чем-то заканчивать (тем же нулём), то на стыке одно название теряется - за этим нужно четко следить.

За названиями каталогов удобнее закрепить 11 символов. Вполне вероятно, что к названию можно присовокупить дату изменения, как ты предложил, но в этом случае каталогов на диск поместится меньше.

Плюсы предложения:
1. Все живет на стандартных местах и не занимает дополнительного места.
2. Любой софт, ничего не знающий о каталогах увидит все файлы на диске в обычном виде без лишних файлов и всего прочего.
3. Системную дорожку можно резервно хранить за пределами 159-го терка.

Минусы предложения:
1. Жесткое ограничение на количество каталогов и файлов.
2. Сортировка угробится в случае несанкционированного MOVE.
3. 9-й сектор используют в своих целях различные программы.

Я высказал идею. Она безусловно хуже чем DirSys, но на мой взгляд лучше, чем то, что предлагаешь ты.

P.S. А DirSys я всё равно не брошу Завсегда можно написать конвертор из одной системы в другую

[random]

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

[key-jee]

Позвольте уже и мне поучаствовать в дискуссии..

При всех высказанных вариантах реализации, вариант spectre мне кажется более приемлемым, однако его использование нужно более серьёзно обезопасить! Заметьте:

Ни какое crc области отношений файлов и директорий не даёт никакой гарантии того, что эти данные верны!!! И уж тем более это утверждение верно для преложенной здесь системы с "магическим числом" Подумайте сами: ведь эти данные хранятся в том секторе, данные которого программами просто не изменяются (я имею в виду именно ту область, в которой хранятся данные о принадлежности), следовательно и подпортить их сложновато и crc почти всегда принимает верное значение!!! То есть нужен какой-то другой способ проверки а не упала ли система?

Я так понимаю у всех возможных надстроек над файловой системой трдос есть весьма уязвимые места:

1. уплотнение диска программой, которая об надстройке не знает приводит к тому, что все файлы, которые находятся после первого стёртого файла с огромной вероятностью переместятся в другой каталог;
2. вероятно, удаление подобными программами последнего (или последних) файлов на диске. Само по себе правда удаление ничего особенного не делает, но если на диске создать новый файл, он автоматически попадает в директорию, в которой находился стёртый до него файл

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

Также предлагаю отвести ещё один сектор для указания проверочных данных (не обязательно crc) на каждый описатель существующего в системе файла, если быть точным, я предлагаю вписывать туда данные длины файла, как самые статичные (2 байта на каждый существующий файл = 256 байт = сектор), ибо таким образом можно защитить систему при move..

Объясняю на примере:

Допустим мы имеем уплотнённый диск, операция move была выполнена из какого-то левого командера..Таким образом, нужно востановить данные на целостность системы..

1. Если была удалена хотя бы одна директория, вероятно что структура востановлению не подлежит..
2. Если все директории остались на месте, стоит произвести проверку всех файлов на длину, и в том месте где длины файлов не совпали (произошло удаление с сопутствующим уплотнением) уплотняем и таблицу принадлежности файлов директориям.. Ну и добавочный сектор нужно уплотнять..
3. Ну а если вы проверили уже то количество файлов, что было зафиксировано в системном секторе, а файлы ещё остались, вероятно это новые файлы, созданные левыми программами.

Про подобные файлы хочу сказать следующее: лучше их в корень поместить по принуждению, а не пользоваться методом предложенным CityAceE

1. У меня есть таблица принадлежности к каталогам всех 128 файлов, то есть даже тех файлов которые еще не существуют.
2. Если перед запуском, скажем, Alasm'а заполнить содержимое ячеек не существующих файлов принадлежностью, например, к каталогу SOURCES, то любой записанный на диск файл окажется в нужном нам каталоге. Или, например, перед запуском программы можно заполнять указанную область номером текущего каталога, таким образом запущенная, например, ArtSudio будет выгружать картинки в каталог где живет сама ArtStudio.

Ведь в эту же директорию потом будут сохранять файлы и те программы, которые запускались с других дисков (это раз) и даже программы с этого же диска, но запущенные непосредственно из trdos или другой программы непонимающей систему директорий (это два)

Итог: в формат системного сектора нужно внести 2 байта (зафиксированное количество директорий и зафиксированное количество файлов) для возможности восстановления системы, и один дополнительный сектор на диске для тех же целей..

пс. Алгоритм правда не без подвоха: если к примеру, на диске была коллекция непакованных scr файлов размещённых по директориям и вы что-то стёрли и уплотнили не пойми откуда ... поплывёт ваша коллекция

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

[key-jee]

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

Неверно! Существующий нынче софт обязательно что-нибудь да грохнет

[key-jee]

4. Названия каталогов хранить в первых 9-ти секторах системной дорожки, при этом хранить их начиная с конца 8-го сектора и далее вниз. То есть файлы растут снизу вверх, а каталоги сверху вниз пока где-то они не встретятся Необходимо помнить, что список файлов закачивается нулем, а каталоги тоже нужно чем-то заканчивать (тем же нулём), то на стыке одно название теряется - за этим нужно четко следить.

А ещё, огромная вероятность того, что софт написанный в настоящий момент на подобную систему плюёт сразу и убивает в первую очередь

[Advertiser]

[Spectre]

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

Представь себе вывод каталога такого диска: загрузка кучи файлов/директорий в которых описывается что к какой директории принадлежит. А простейший перенос файла из одной директории в другую потребует изменения 0-ой дорожки и 2-х файлов/директорий.

А ещё, огромная вероятность того, что софт написанный в настоящий момент на подобную систему плюёт сразу и убивает в первую очередь

Абсолютно верно, тот же Quick Commander после последнего файла все заполняет нулями. И таких программ много - это считается хорошим стилем.

[Spectre]

1. Все что лежит за гранью первых 9 секторов ты не приемлешь из соображений невозможности найти места в существующем софте, пусть даже это будут всего 512 байт.
2. Вариант с MagicNumber поддержан.
3. Вариант с записью в таблицу принадлежности, чтобы файлы оказались в нужном месте, поддержан.

Я тут обдумал все предложения и решил что разумно:
1. Да.
2. CRC вообще убрать (при MagicNumber в нем мало смысла), вместо этого стоит придумать некоторую избыточность для возможности не просто определить что система легла, а попытаться ее восстановить (key-jee). Позже напишу свой вариант избыточности.
3. Запись в таблицу представить как "Выбор директории по умолчанию", то есть отдельную опцию в коммандере.

Напрягаю свою мозговую извилину и рожаю вот такой вариант:

1. Суммарное число файлов и каталогов не может превышать какого-то максимума Это количество зависит от формата хранения имени каталога и соотношения количества файлов и каталогов на диске (см. ниже).
2. Таблицу (длинной N байт) принадлежности файлов к каталогам и каталогов к каталогам держать в 9-м системном секторе. Там же держать дескриптор системы и контрольную сумму и др. необходимую информацию.
4. Названия каталогов хранить в первых 9-ти секторах системной дорожки, при этом хранить их начиная с конца 8-го сектора и далее вниз. То есть файлы растут снизу вверх, а каталоги сверху вниз пока где-то они не встретятся Необходимо помнить, что список файлов закачивается нулем, а каталоги тоже нужно чем-то заканчивать (тем же нулём), то на стыке одно название теряется - за этим нужно четко следить.

А где (3)? С (1) это и так очевидно, в случае TRDIR n=128. Пункту (2) TRDIR удовлетворяет. А вот с (3) есть проблемы: во-первых (как уже писали выше) программы любят затирать область после последнего файла нулями (это важно), а во-вторых не так удобно выводить каталог как в случае с TRDIR (это совсем не критично). Но вариант интересный.

P.S. А DirSys я всё равно не брошу Завсегда можно написать конвертор из одной системы в другую

Собственно они друг другу совсем не мешают.

[CityAceE]

Абсолютно верно, тот же Quick Commander после последнего файла все заполняет нулями. И таких программ много - это считается хорошим стилем.

Хочу сказать, что если человек пользуется каким-то коммандером, который он избрал для себя в качестве основного, то с высокой степенью вероятности он не будет использовать какой-то другой коммандер и уж тем более пользоваться "консолью" TR-DOS. Если этот коммандер будет поддерживать какую-то систему каталогов, то такому юзеру будет глубоко по-барабану, что какой-то другой коммандер порушит его каталоги, лишь бы нарушение системы каталогов никак не отразилось на стандартную файловую систему TR-DOS. Вот исходя из этого и можно отталкиваться создавая новую систему каталогов. Всё равно сделать такую систему, которая будет удовлетворять всем требованиям, будет неубиваемой, неконфликтной и т.д. и т.п. нереально.

На этом мои мысли пока иссякли. Добавить к сказанному мне нечего. Жду кто что скажет ещё

P.S. Этот тред больше подходит к разделу "Оси". Может перенести?

[random]

Представь себе вывод каталога такого диска: загрузка кучи файлов/директорий в которых описывается что к какой директории принадлежит. А простейший перенос файла из одной директории в другую потребует изменения 0-ой дорожки и 2-х файлов/директорий.

какие проблемы при выводе? при загрузке подгрузить маленьких файлов (по сектору) описаний директорий? перенос файла из одной в другую это перепись 2 1 секторовых файлов. причем здесь 0 дорожка?

скорость работы страдает на децел по сравнению с хранением диров в самом каталоге. а такую систему не угробить никакими мувами.

не вижу проблемы.