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

[Spectre]

Не один раз и не одним человеком предпринимались попытки создать систему каталогов на TR-DOS дисках. Самая известная попытка - это DirSys by Станислав Юдин. Но попытавшись поддержать ее в своей программе программист столкнется с трудностью вывода каталог диска (из-за того, что каталоги и файлы хранятся отдельно), необходимостью загружать не первые 9 секторов 0-ой дорожки, а 15 (хотя можно загрузить только 11 секторов, но куда тогда денутся "обрезанные" каталоги и как правильно подсчитать CRC?). Также не следует забывать про то что кнопка Magic или boot в 0-ой дорожке быстро и надежно уничтожат все ваши каталоги. Таким образом нехватка памяти под хранение двух 15-и секторных каталогов дисков с одной стороны и сложность вывода каталога диска с другой стороны, вынудило придумать новую систему хранения каталогов, лишенную этих недостатков. На данный момент 2-я людьми (Pawel Kyslyak и Andrey Bogdanovich), известными как авторы популярных Real Commander и Quick Commander составлено черновое описание новой системы каталогов. Рабочее название "TRDIR". В ближайшем будущем именно эту систему будут поддерживать 2 самых популярных коммандера (согласно опросу в соседней ветке). Приглашаем всех желающих обсудим детали и внести свои предложения для создания единого стандарта хранения каталогов.

Я понимаю что у многих возникнет мысль: "А зачем вообще нужны каталоги на дисках со 128-ю файлами?". Моя точка зрения в том, что стандарт нужен хотя-бы потому что 128 файлов это не так уж мало, а также на будущее, когда 1-2Мб RAM-диск или 1Мб раздел на винчестере будут распространены. Наше дело содать и внедрить стандарт, а уже пользователи пускай решают пользоваться каталогами или нет. Поэтому прошу в этой ветке воздержаться от фраз "Это не никому нужно", а попробовать найти и указать недостатки, а также пути исправления недостатков в новой системе.

Описание системы каталогов TRDIR

Чтобы не было путаницы: каталог - это каталог диска, директория - это каталог созданный на диске.

Информация о системе директорий хранится в неиспользуемом месте системного сектора (8-ой сектор 0-ой дорожки). Имена директорий создаются как файлы нулевой длины. В таблице отношений каждому байту соответствует свой файл в каталоге TR-DOS. Значение из соответствующей файлу ячейки ссылается на номер директории (файла пустышки) к которому он принадлежит. Значение #ff в ячейке означает что файл принадлежит корневой директории.

Формат системного сектора:
+#20 (128 байт) таблица отношений файлов и директорий.
+#A0 (2 байта) CRC области #20 - #9F.
+#A2 (5 байт) идентификатор системы "TRDIR".
+#A7 (1 байт) номер версии "1" (#31).

Директории (при их создании) всегда помещаются в начало каталога, а имена файлов после них. Благодаря этому директории легко отслеживаются по нулевой длине и указателю на 0-ой сектор 1-ой дорожки. Пример каталога с директориями:

Имя    Старт  Длина(байт.)  Длина(сек.)  Сектор  Дорожка
               (дата изм.)
               
Music            0000           00         00      01
Programms!       1105           00         00      01
boot    B        0250           01         00      01
screen  scr      6912           1b         01      01

Поле длины директорий содержит дату изменения. Дата меняется если в директорию дописывают или удаляют файлы. Если происходит переименование дата не меняется. Формат даты (полубайтами): день+месяц и мл.байт+ст.байт года, берется из CMOS часов. Если CMOS часов у пользователя нет или программа не умеет с ними работать, тогда в поле сохраняется число #0000. При печати имени это отслеживается и не выводится дата если там нули.

Формат имен директорий:
+#00 (11 байт) имя
+#0B (2 байта) дата создания каталога
+#0D (3 байта) длина_в_секторах/сектор/дорожка = #00 #00 #01

Параметр длина в секторах, сектор и дорожка файла содержат правильные параметры для обеспечения корректного рассчёта длины файлов.

[Advertiser]

[CityAceE]

необходимостью загружать не первые 9 секторов 0-ой дорожки, а 15 (хотя можно загрузить только 11 секторов, но куда тогда денутся "обрезанные" каталоги и как правильно подсчитать CRC?). Также не следует забывать про то что кнопка Magic или boot в 0-ой дорожке быстро и надежно уничтожат все ваши каталоги.

В предложенном варианте мне не нравится как минимум то, что совокупное количество файлов и каталогов не может превышать 128. А иной раз и отведенного количества на 128 файлов на диске оказывается мало

А сейчас буду защищать свою DirSys
В системе есть байты отвечающие за номер версии. Если увеличить номер версии, то можно кое-что и поправить в системе Я думал об улучшении и упрощении своей системы каталогов DirSys и вот что надумал:
1. Чтобы было упростить работу с подсчетом контрольной суммы можно ввести по аналогии с архивами ZIP некий MagicNumber - это такое фиксированное значение контрольной суммы при котором программа считает, что каталог цел.
2. DirSys в своем минимуме может занимать всего 2 сектора (512 байт), этого объёма хватит чтобы иметь информацию о 22-х каталогов. На мой взгляд этого количества более чем достаточно! Можно спокойно ограничится этим количеством. К тому же в системе есть зарезервированный байт, в котором можно хранить количество каталогов и таким образом грузить не все сектора, а только те, в которых содержатся имена каталогов. Если места мало, все равно можно грузить только 2 сектора, а тем каталогам, имена который не влезли при загрузке присвоить какие-то рабочие имена типа Dir1, Dir2 и т.д.
3. Чтобы решить проблему с убиванием системы при нажатии на Magic и другими случаями порчи системы, можно разрешить системе жить не на нулевой дорожке, а в отдельном файле фиксированной длины от 2-х (22 каталога) до 7-ми (128 каталогов) секторов.
5. Я написал коммандер с поддержкой DirSys, тем самым продемонстрировал полую работоспособность системы. При чем по мере написания я сталкивался с проблемами изменял систему так, чтобы она стала полностью работоспособной.
4. Не забывайте, что уже существуют программы (их очень мало, но они есть ), которые поддерживают DirSys. Ярким примером является плагин к FAR'у xTRD.

[Bulba]

4. Не забывайте, что уже существуют программы (их очень мало, но они есть ), которые поддерживают DirSys. Ярким примером является плагин к FAR'у xTRD.

Не могу вспомнить какой-именно, но есть журнал, где файлы раскиданы по директориям. Я не так давно установил плагины для Far'а c поддержкой DirSys, и когда зашел в этот TRD, у меня чуть челюсть не выпала

[Spectre]

В предложенном варианте мне не нравится как минимум то, что совокупное количество файлов и каталогов не может превышать 128. А иной раз и отведенного количества на 128 файлов на диске оказывается мало

Это пока единственный недостаток. Чтобы избежать остальных недостатков я и вынес спецификацию системы на широкое обсуждение.
Что касается его:
1) У меня из примерно 200 TRD'шек только 2 содержат 128 файлов, то есть 1%
2) На борьбу с этим есть архиваторы вроде hrip, zxzip, zxrar

А сейчас буду защищать свою DirSys
В системе есть байты отвечающие за номер версии. Если увеличить номер версии, то можно кое-что и поправить в системе Я думал об улучшении и упрощении своей системы каталогов DirSys и вот что надумал:
1. Чтобы было упростить работу с подсчетом контрольной суммы можно ввести по аналогии с архивами ZIP некий MagicNumber - это такое фиксированное значение контрольной суммы при котором программа считает, что каталог цел.

Это хорошая идея, вроде AlCo подобное предлагал. Предлагаю "стандартные" #aa55.

2. DirSys в своем минимуме может занимать всего 2 сектора (512 байт), этого объёма хватит чтобы иметь информацию о 22-х каталогов. На мой взгляд этого количества более чем достаточно! Можно спокойно ограничится этим количеством. К тому же в системе есть зарезервированный байт, в котором можно хранить количество каталогов и таким образом грузить не все сектора, а только те, в которых содержатся имена каталогов. Если места мало, все равно можно грузить только 2 сектора, а тем каталогам, имена который не влезли при загрузке присвоить какие-то рабочие имена типа Dir1, Dir2 и т.д.

Суть проблемы в том, что есть уже написанный софт в который надо добавить поддержку каталогов.

Возмем например Real Commander v2.x - самый популярный коммандер согласно опросу. В нем фиксировано: #6000-#68ff - активный каталог, #6900-#71ff - пассивный каталог. На такую структуру ориентированы уже написанные модули, память #7200 и выше давно распределена. Как туда добавить DirSys? И не слишком ли жирно будет 4 сектора основной памяти выделять под то, что можно сделать в свободном месте системного сектора?

Возмем мой Quick Commander, в нем 4 сектора памяти я найти могу, но у меня другая проблема возникла при интеграции DirSys: все процедуры знают, что позиция курсора = номеру файла на котором он стоит. Если перед файлами появятся директории (по которым тоже может ездить курсор), то позиция курсора будет >= номера файла под ним, то есть придется добавить пересчет практически в каждой процедуре.

Подобные (и другие) проблемы будут возникать при интеграции в уже написанные программы. А поскольку новых программ пишут мало, а в старые DirSys добавить сложно, имеем то что имеем - DirSys поддерживает пара-тройка программ.

3. Чтобы решить проблему с убиванием системы при нажатии на Magic и другими случаями порчи системы, можно разрешить системе жить не на нулевой дорожке, а в отдельном файле фиксированной длины от 2-х (22 каталога) до 7-ми (128 каталогов) секторов.

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

Про то и речь: давай с чистого листа сделаем новую систему свободную от недостатков DirSys! Можно ее хоть DirSys2 назвать, лишь бы это был единый удобный стандарт.

5. Я написал коммандер с поддержкой DirSys, тем самым продемонстрировал полую работоспособность системы. При чем по мере написания я сталкивался с проблемами изменял систему так, чтобы она стала полностью работоспособной.
4. Не забывайте, что уже существуют программы (их очень мало, но они есть ), которые поддерживают DirSys. Ярким примером является плагин к FAR'у xTRD.

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

[CityAceE]

Это пока единственный недостаток.

Ну не скажи, единственный...
1. Не все пользуются RC и QC. Я думаю, что больше пользователей пользуются FAR'ом. Те кто не пользуются этим двумя коммандерами вместо каталогов увидят файлы-пустышки. Удобно? Нет!
2. Как и в случае с DirSys сортировка файлов по каталогам убьётся, если сделать MOVE самой системой TR-DOS или коммандером, который ничего не знает про каталоги.
3. Опять же есть софт который в системном секторе хранит свою информацию, соответственно погубит предлагаемую систему.

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

Чтобы избежать остальных недостатков я и вынес спецификацию системы на широкое обсуждение.

И правильно сделал!
Что касается его:

1) У меня из примерно 200 TRD'шек только 2 содержат 128 файлов, то есть 1%

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

2) На борьбу с этим есть архиваторы вроде hrip, zxzip, zxrar

Выход, но безусловно совершенно не удобный.

Это хорошая идея, вроде AlCo подобное предлагал. Предлагаю "стандартные" #aa55.

Число потом можно будет обсудить, главное идея. Будем считать, что она принята на вооружение.

[CityAceE]

Суть проблемы в том, что есть уже написанный софт в который надо добавить поддержку каталогов.

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

Возмем например Real Commander v2.x - самый популярный коммандер согласно опросу. В нем фиксировано: #6000-#68ff - активный каталог, #6900-#71ff - пассивный каталог. На такую структуру ориентированы уже написанные модули, память #7200 и выше давно распределена. Как туда добавить DirSys? И не слишком ли жирно будет 4 сектора основной памяти выделять под то, что можно сделать в свободном месте системного сектора?

Безусловно DirSys туда не добавить все по той же причине - коммандер не был заточен под многокаталоговую систему от рождения и у него нет памяти под это дело

Возмем мой Quick Commander, в нем 4 сектора памяти я найти могу, но у меня другая проблема возникла при интеграции DirSys: все процедуры знают, что позиция курсора = номеру файла на котором он стоит. Если перед файлами появятся директории (по которым тоже может ездить курсор), то позиция курсора будет >= номера файла под ним, то есть придется добавить пересчет практически в каждой процедуре.

Опять же при написании QC ты не задумывался о каталогах - результат ты описал выше.

А теперь опишу как устроен мой коммандер. Сразу отмечу, что он полностью работоспособен на 48К и при этом имеет буфер под копирование в 16К.
#6000-#6FFF - нулевая дорожка левой панели
#7000-#7FFF - нулевая дорожка правой панели
#8000-#AFFF - код коммандера
#C000-#DFFF - буфер под просмотр текста, картинок, переменные и т.д.
#E000-#EFFF - текущий каталог левого диска
#F000-#FFFF - текущий каталог правого диска

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

И тем не менее мой коммандер с поддержкой каталогов живет уже несколько лет и немногочисленные отзывы я все же получал. Основная просьба юзеров дать системе жить в отдельном файле. Мне лично сделать это в своей софтине очень легко. Поэтому никак нельзя игнорировать эту идею. Во всяком случае ее нужно тщательно обсудить!

Про то и речь: давай с чистого листа сделаем новую систему свободную от недостатков DirSys! Можно ее хоть DirSys2 назвать, лишь бы это был единый удобный стандарт.

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

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

В моей системе есть два слабых места:
1. Гробится MAGIC'ом и аналогичными ситуациями.
2. Нарушается при использовании MOVE.
Однако если пользователю не нужны каталоги, то это не фатально. Если каталоги нужны, то указанные ситуации можно избежать.

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

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

Все что я высказал выше - это результат работы над NRDN, перепиской с пользователями и глубокого анализа. И это всего лишь мое мнение. Я уверен, что если вы придумаете что-то другое, то пользователи будут пользоваться вашей системой Но по-моему глубоко ошибочно загонять систему в рамки существующего софта!

[CityAceE]

Не могу вспомнить какой-именно, но есть журнал, где файлы раскиданы по директориям. Я не так давно установил плагины для Far'а c поддержкой DirSys, и когда зашел в этот TRD, у меня чуть челюсть не выпала

Это был AlCo со своими журналами, а использовал он DirSys.

[jtn]

Если не нравится DyrSys, то почему бы не использовать систему как в TomberBoot?

[Lion17]

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

[CityAceE]

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

С точки зрения софта, не знающего о системе, нельзя, с точки зрения TR-DOS Navigator'а такого ограничения нет ибо он полагается не на имя файла, а на его порядковый номер. Теоретически все 128 файлов могут иметь одинаковые имена и TRDN будет отличать их друг от друга.