PDA

Просмотр полной версии : Новая система каталогов в TR-DOS



Spectre
05.02.2005, 17:26
Не один раз и не одним человеком предпринимались попытки создать систему каталогов на 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
Параметр длина в секторах, сектор и дорожка файла содержат правильные параметры для обеспечения корректного рассчёта длины файлов.

CityAceE
05.02.2005, 17:51
необходимостью загружать не первые 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
05.02.2005, 18:12
4. Не забывайте, что уже существуют программы (их очень мало, но они есть :) ), которые поддерживают DirSys. Ярким примером является плагин к FAR'у xTRD.

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

Spectre
05.02.2005, 19:01
В предложенном варианте мне не нравится как минимум то, что совокупное количество файлов и каталогов не может превышать 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
06.02.2005, 04:47
Это пока единственный недостаток.
Ну не скажи, единственный...
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
06.02.2005, 04:48
Суть проблемы в том, что есть уже написанный софт в который надо добавить поддержку каталогов.
Суть в другом! Ты думаешь о том, каким бы образом запихнуть каталоги в программы, которые отродясь не думали о них. И получается, что это дело идет в ущерб юзеру. Ведь юзера мало волнует что в коммандере места мало - ему нужно удобство. Я когда запланировал совой коммандер сразу делал акцент на каталоги и теперь я могу поддержать практически любую каталоговую систему будь то 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
06.02.2005, 04:50
Не могу вспомнить какой-именно, но есть журнал, где файлы раскиданы по директориям. Я не так давно установил плагины для Far'а c поддержкой DirSys, и когда зашел в этот TRD, у меня чуть челюсть не выпала ;)
Это был AlCo со своими журналами, а использовал он DirSys.

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

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

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

Spectre
06.02.2005, 16:04
Ну не скажи, единственный...
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
06.02.2005, 17:34
Не буду тебя цитировать, а то потом никому читать не удобно. Лишь подытожу :)
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
06.02.2005, 17:57
может я чего-то недогоняю, но почему не сделать директорию очередным файлом в системе. в этом файле будет храниться принадлежность файлов и информацию по каталогу. тогда ничего при MOVE гробиться не будет и никаких проблем с другим софтом.

key-jee
06.02.2005, 21:43
Позвольте уже и мне поучаствовать в дискуссии..

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

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

Я так понимаю у всех возможных надстроек над файловой системой трдос есть весьма уязвимые места:
уплотнение диска программой, которая об надстройке не знает приводит к тому, что все файлы, которые находятся после первого стёртого файла с огромной вероятностью переместятся в другой каталог;
вероятно, удаление подобными программами последнего (или последних) файлов на диске. Само по себе правда удаление ничего особенного не делает, но если на диске создать новый файл, он автоматически попадает в директорию, в которой находился стёртый до него файл
Поэтому предлагаю считать систему упавшей, если количество директорий в каталоге диска не равно завиксированному количесва директорий в системном секторе.. хотя есть вероятность, что кто-то попытался сосздать директорию, но сделал это не совсем корректно

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

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

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

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

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

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

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

key-jee
06.02.2005, 22:39
может я чего-то недогоняю, но почему не сделать директорию очередным файлом в системе. в этом файле будет храниться принадлежность файлов и информацию по каталогу. тогда ничего при MOVE гробиться не будет и никаких проблем с другим софтом.Неверно! Существующий нынче софт обязательно что-нибудь да грохнет :D

key-jee
06.02.2005, 22:42
4. Названия каталогов хранить в первых 9-ти секторах системной дорожки, при этом хранить их начиная с конца 8-го сектора и далее вниз. То есть файлы растут снизу вверх, а каталоги сверху вниз пока где-то они не встретятся :) Необходимо помнить, что список файлов закачивается нулем, а каталоги тоже нужно чем-то заканчивать (тем же нулём), то на стыке одно название теряется - за этим нужно четко следить.А ещё, огромная вероятность того, что софт написанный в настоящий момент на подобную систему плюёт сразу и убивает в первую очередь :D

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

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


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

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

Spectre
07.02.2005, 00:34
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
07.02.2005, 05:00
Абсолютно верно, тот же Quick Commander после последнего файла все заполняет нулями. И таких программ много - это считается хорошим стилем.
Хочу сказать, что если человек пользуется каким-то коммандером, который он избрал для себя в качестве основного, то с высокой степенью вероятности он не будет использовать какой-то другой коммандер и уж тем более пользоваться "консолью" TR-DOS. Если этот коммандер будет поддерживать какую-то систему каталогов, то такому юзеру будет глубоко по-барабану, что какой-то другой коммандер порушит его каталоги, лишь бы нарушение системы каталогов никак не отразилось на стандартную файловую систему TR-DOS. Вот исходя из этого и можно отталкиваться создавая новую систему каталогов. Всё равно сделать такую систему, которая будет удовлетворять всем требованиям, будет неубиваемой, неконфликтной и т.д. и т.п. нереально.

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

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

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

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

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

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

CityAceE
07.02.2005, 07:00
а такую систему не угробить никакими мувами.
Так или иначе принадлежность файлов к каталогам нужно как-то отслеживать и выбрать для этого какой-то признак, который будет отличать один файл от другого. В DirSys это порядковый номер, но можно также опираться на имя файла. Так вот если сделать MOVE, и система опирается на порядковый номер файла, то сортировка по каталогам пострадает. Если опираться на имя файла, то такаф система потребует больше места на диске и сортировка все равно порушится если файл будет переименован. Так что как ни крути систему всегда можно порушить.

elf/2
07.02.2005, 11:50
пара идей/комментариев:

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

2. magicNumbers - плохо, key-jee - прав. если я правильно понял что вы имеете в виду, то существующй id системы (TRDIR1 или DirSys1.00) может играть роль magicNumber. для проверки целостности системы подобный подход не подходит :)

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

4. уж если хранить дату, то надо хранить и время (урезаем имя директории до 9 символов, время укладываем в start)

5. если файлы растут навстречу директориям (предложил CityAceE), то система увивается простым созданием новых файлов в старых тулзах

ну и самый главный вопрос: готовы ли разработчики других системных программ поддержать какую-нибудь систему директорий? (другими словами: что думает по этому поводу AlCo?)

key-jee
07.02.2005, 20:32
1. как системе выжить при move - в табличке принадлежности файлов (128 байт) у нас есть неиспользованный старший бит. будем в нем дублировать информацию о том живой у нас файл или удаленный. если я правильно понимаю, после того как будет сделан move посторонней тулзой этих битиков достаточно для восстановления системы. есть еще более суровый вариант: файлы в каталоге вообще не помечаются как удаленные (информацию храним в этих битиках). тогда старые тулзы вообще move делать не будут.Ты знаешь, я такой вариант уже продумал, мне даже казалось, что старший бит использовать нельзя ибо файлов на диске может быть от 0 до 128 (0x00 - 0x80), правда я понял такую вещь, что даже если все файлы являются каталогами, то максимально последний файл может относиться к 127 каталогу.. А вообще, ты забываешь, что удалить файл я могу именно другой программой, затем и move в ней сделать.. тогда система точно также не выживет.

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

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

elf/2
07.02.2005, 22:13
А вообще, ты забываешь, что удалить файл я могу именно другой программой, затем и move в ней сделать.. тогда система точно также не выживет.
я не забыл об этом, просто сначала все боялись только move'а. ясен пень что 100% восстанавливаемую систему сделать вряд ли получиться.
если необходимо предохраниться от del+move, то можно посчитать crc (на самом деле подойдет любой алгоритм) размером 1 байт для заголовка каждого файла без стартового трека/сектора и положить на свободное место в каталоге (перед системным сектором или после, на это уйдет 128 байт, соответсвенно если на диске меньше 120 файлов то можно хранить перед системным сектором). с достаточной степенью вероятности этой информации хватит чтобы восстановить систему после большинства операций.



Кстати, раз уж у вас есть желание того, чтобы формат поддержали разработчики нового софта.. постарайтесь сделать систему такой, чтоб для сохранения файлов и создания каталогов не было необходимости высчитывать всяческие crc и прочее - это лишние процедуры для кодеров!!!
странно, процедура подсчета crc много места занять не должна. а для ленивых :) кодеров ее надо положить в дистрибутив коммандера и/или описание формтата системы.
imho, наличие/отсутсвие необходимости подсчета crc не влияет на наличие/остутсвие поддержки системы в новом софте.

key-jee
08.02.2005, 05:11
я не забыл об этом, просто сначала все боялись только move'а. ясен пень что 100% восстанавливаемую систему сделать вряд ли получиться.
если необходимо предохраниться от del+move, то можно посчитать crc (на самом деле подойдет любой алгоритм) размером 1 байт для заголовка каждого файла без стартового трека/сектора и положить на свободное место в каталоге (перед системным сектором или после, на это уйдет 128 байт, соответсвенно если на диске меньше 120 файлов то можно хранить перед системным сектором). с достаточной степенью вероятности этой информации хватит чтобы восстановить систему после большинства операций..Ошибаешься, есть ещё операция rename, которой можно изменить первые 11 байт любого файла (у бейсик файлов - 8). плюсуем к этому 2 байта стартовых дорожки и сектора и остаётся всего 3 байта длины - поэтому я и предложил сохранять два байта длины в отдельный сектор (без длины в секторах). Тогда вероятность восстановления файлов есть, и запись на диск в таких случаях выглядит примитивно

key-jee
08.02.2005, 05:27
заметьте, что для возможности восстановления необходимо хранить где-то определённую информацию на каждый "зарегистрированный" системой файл, чтобы она знала какие файлы существовали а какие появились в результате сохранения из других программ.. Заметьте, даже 128 байт свободных в первых 9ти секторах уже нет..

CityAceE
08.02.2005, 05:32
1. как системе выжить при move - в табличке принадлежности файлов (128 байт) у нас есть неиспользованный старший бит. будем в нем дублировать информацию о том живой у нас файл или удаленный. если я правильно понимаю, после того как будет сделан move посторонней тулзой этих битиков достаточно для восстановления системы. есть еще более суровый вариант: файлы в каталоге вообще не помечаются как удаленные (информацию храним в этих битиках). тогда старые тулзы вообще move делать не будут :).
Великолепная идея! Возьму-ка я её на вооружение в следующей версии DirSys. Пока правда не могу до конца сообразить как восстановить сортировку по каталогам после стороннего MOVE, но нутром чую, что это более чем реально! :) Конечно, если сделать DEL и следом MOVE в стороннем коммандере, то сортировку на восстановить, а вот если только MOVE, то можно. Это лучше чем ничего!

elf/2
08.02.2005, 11:32
Ошибаешься, есть ещё операция rename, которой можно изменить первые 11 байт любого файла (у бейсик файлов - 8). плюсуем к этому 2 байта стартовых дорожки и сектора и остаётся всего 3 байта длины - поэтому я и предложил сохранять два байта длины в отдельный сектор (без длины в секторах). Тогда вероятность восстановления файлов есть, и запись на диск в таких случаях выглядит примитивно
переименование как раз ничего не портит :)
предложенный вариант хранит не отдельные crc, а их последовательность. соответственно после последовательности неких действий в другом софте мы имеем две таблички crc - старая и новая. для восстановления сортировки файлов по каталогам нам надо построить отображение новых номеров файлов на старые. какие деструктивные операции могут быть мы знаем, как они влияют на табличку тоже. в случае с rename у нас таблички отличаются одной crc где-то в середине. никто не мешает в этом случае решить, что это то же самое файло. в случае сомнений можно "проблемные" файлы бросить в корневой каталог и сообщить об этом пользователю или спросить у него подтверждения. в принципе алгоритм не совсем тривиальный, но восстановление системы можно вынести в отдельный модуль/плагин и грузить его по необходимости

вообще пока я вижу только одну проблему: del несколько последних файлов - создали столько-же файлов --- визуально это то же самое что мы переименовали исходные файлы.

elf/2
08.02.2005, 11:34
заметьте, что для возможности восстановления необходимо хранить где-то определённую информацию на каждый "зарегистрированный" системой файл, чтобы она знала какие файлы существовали а какие появились в результате сохранения из других программ.. Заметьте, даже 128 байт свободных в первых 9ти секторах уже нет..
можно ограничить число файлов+каталогов до 120. или положить эту таблицу в 10й сектор. если ее убъет migic - ну и хрен с ней (для работы системы она не является критичной, ее всегда можно посчитать заново)

elf/2
08.02.2005, 11:49
Великолепная идея! Возьму-ка я её на вооружение в следующей версии DirSys. Пока правда не могу до конца сообразить как восстановить сортировку по каталогам после стороннего MOVE, но нутром чую, что это более чем реально! :) Конечно, если сделать DEL и следом MOVE в стороннем коммандере, то сортировку на восстановить, а вот если только MOVE, то можно. Это лучше чем ничего!
дык! :)
только тебе целый дополнительный сектор понадобиться :(
del+move - нужна еще одна таблица (1-2 байта на файл [crc заголовка])

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

в случае TRDir чуть посложнее, но тоже можно.

главное не забывать что процесс восстановления может быть интерактивным...

Spectre
09.02.2005, 00:57
Итак, подытожим:

В целом TRDIR подходит, но необходимо произвести изменения с целью повысить устойчивость системы к нарушению структуры каталогов "старыми" утилитами.

Возможные изменения каталога утилитами без поддержки TRDIR:

1. Переименование файла
2. Удаление файла/директории
3. Восстановление удаленного файла
4. Копирование (создание нового) файла
5. И наконец он, монстр из ваших снов :) MOVE!
6. Запись в служебный сектор (в таблицу ссылок) :eek:

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

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

Если произошло (5) или (6): отключить поддержку TRDIR, в комплекте с коммандерами распространять интерактивную утилиту восстановления директорий.

Я за все это время ничего нового не придумал. :(

Итоги:
1. 7-ой бит в таблице ссылок обозначает удален файл (bit=1) или нет (bit=0). В связи с тем что корневая директория обозначается ссылкой #FF, вводится ограничение на общее число директорий - 127 (а не 128 как ранее).
2. Убрать CRC.
3. Добавить общее число файлов и первый свободный трэк/сектор (или число свободных секторов).

key-jee
09.02.2005, 04:43
(5) можно задетектить по таблице удаленных файлов и сохраненному общему числу файлов (вместе с директориями) на диске, исправить сложно, особенно если не создавать доп. проверочных секторов (а места под них считаем что нет).Ну я не знаю. Всё-таки прошло то время, когда было модно сохраняться в 0ой трек. В основном благодаря эмуляторам и образам дисков типа scl, где 0ая дорога просто не сохраняется. Так что вот вам ещё один недостаток системы, которая хранит информацию в 0 дороге, а не в файле ;)

Кстати грузить 10 секторов вместо 9ти не так уж и напряжно


7-ой бит в таблице ссылок обозначает удален файл (bit=1) или нет (bit=0). В связи с тем что корневая директория обозначается ссылкой #FF, вводится ограничение на общее число директорий - 127 (а не 128 как ранее).А смысл? ведь если считать 0 корневым каталогом, то 1ый дир может принадлежать корню, а 128ой - 127ому каталогу, то есть в любом случае в таблице принадлежности не используется старший бит, если уж ограничивать, то к примеру 63 или 31, хоть какой-то смысл появляется :)

elf/2
09.02.2005, 13:22
и до кучи распространить 'reference implementation' в исходниках. т.е. набор процедур для базовых операций (проверить наличие системы, создать/удалить директорию, найти номер директории по полному пути, положить файл в директорию, etc)

Pawel
09.02.2005, 23:32
1. Никакая защита от move не нужна, вспомните когда вы последний раз делали эту операцию не в своём любимом командере. Я бы попросту не рискнул ;). А уж помня что диск с директориями...
2. CRC убирать нельзя, в крайнем случае заменить на что-то типа контрольной суммы. А процедура подсчёта CRC в RC уже есть ;) (для SMUC CMOS).
3. В дублировании количества файлов и свободного места также нет большого смысла, так как ситуация с попаданием записанного файла в другой каталог маловероятна (как часто вы "вручную" удаляете файлы из TR-DOS или каких либо других прог ?). А если файл перезаписывается с таким же именем, то и вполне логично что он должен попасть в ту же директорию где лежал старый. Только представьте что почти каждый раз загружая командер после работы с другим софтом вы будете получать запрос переместить ли изменившийся последний файл в корневую директорию.

Aprisobal
09.02.2005, 23:45
Так что вот вам ещё один недостаток системы, которая хранит информацию в 0 дороге, а не в файле Тогда давайте вообще в конце файла boot.B(он должен быть 64sec) хранить каталог :D

MadCat!
10.02.2005, 15:19
предлагаю для облегчения поддержки dir'ов в любом новом софте сделать сабж.
идеальный вариант - одинаковый API и для QC, и для RC.
правда, здесь нельзя ошибаться, чтоб не появился еще один "косячный стандарт" ;)

Spectre
10.02.2005, 19:50
предлагаю для облегчения поддержки dir'ов в любом новом софте сделать dir API в rom-версиях коммандеров .
идеальный вариант - одинаковый API и для QC, и для RC.
правда, здесь нельзя ошибаться, чтоб не появился еще один "косячный стандарт" ;)

А что это такое? Отдельный файл с процедурами работы с директориями? Коммандер очень специфичная утилита и такое большое добавление как поддержка директорий, потребует очень серьезных изменений самых разных процедур внутри коммандеров. Вынести все эти изменения в отдельный файл трудно, и совсем не нужно.

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

Spectre
10.02.2005, 20:00
1. Никакая защита от move не нужна, вспомните когда вы последний раз делали эту операцию не в своём любимом командере. Я бы попросту не рискнул ;). А уж помня что диск с директориями...

Как в одном анекдоте: "случаи они разные бывают... :)"

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


2. CRC убирать нельзя, в крайнем случае заменить на что-то типа контрольной суммы. А процедура подсчёта CRC в RC уже есть ;) (для SMUC CMOS).

А толку с нее? Я думаю что после загрузки каталога нового диска будет вызываться некоторая процедура, которая анализировав структуру директорий, метку, выносит вердикт: все нормально или работа с директориями невозможна. Если структура нарушена, процедура это дело отловит.


3. В дублировании количества файлов и свободного места также нет большого смысла, так как ситуация с попаданием записанного файла в другой каталог маловероятна (как часто вы "вручную" удаляете файлы из TR-DOS или каких либо других прог ?). А если файл перезаписывается с таким же именем, то и вполне логично что он должен попасть в ту же директорию где лежал старый. Только представьте что почти каждый раз загружая командер после работы с другим софтом вы будете получать запрос переместить ли изменившийся последний файл в корневую директорию.

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

MadCat!
11.02.2005, 13:41
А что это такое? Отдельный файл с процедурами работы с директориями?Не отдельный файл, а набор точек входа и процедур в ПЗУ (я ж про rom-версии коммандеров писал). Это позволит кодерам не копировать один и тот же код, а по возможности использовать прошитые процедуры.
Например, у меня в проге нет памяти совсем на "прилагаемые готовые процедуры", но если они в есть rom, (я могу по сигнатуре или еще как-нибудь узнать об этом), то для поддержки TRDIR нужно всего несколько CALL'ов...

Коммандер очень специфичная утилита и такое большое добавление как поддержка директорий, потребует очень серьезных изменений самых разных процедур внутри коммандеров. Вынести все эти изменения в отдельный файл трудно, и совсем не нужно.трудно=>не нужно :D да, кодеры всегда были ленивыми (это я о себе) ;)
IMHO такой универсальный API всё же полезен, но сделать его правильно действительно непросто...

К коммандерам в любом случае будут прилагаться готовые процедуры для работы с TRDIR.Ясно.
Кто-нибудь ещё что-нибудь думает по этому поводу?

GriV
21.02.2005, 13:22
от TRDOS как таковой вообще?
Всем понятно, что даже если инфу хранить на дискетах, то дискеты не HDD, они ж (дискеты) портятся! Как обходить царапины? Какой механизм фрагментаци? Дата создания? Права доступа? Каталоги? Изменение формата? Длинные имена? Большой размер? Если смотреть с точки зрения совместимости с TR-DOS, то DirSys на 100% удовлетворяла нужду в каталогах (которые по большому счёту большинством пользователей не очень нужны по причине слобости базы - именно файловой системы TR-DOS).
Нафиг огород городить? Хотите работать со старыми программами - используйте TR-DOS базовую файловую систему, на крайний случай -DirSys. Хотите работать комфортно - берите другую систему, где всё учтено.

Spectre
21.02.2005, 17:14
от TRDOS как таковой вообще?
Всем понятно, что даже если инфу хранить на дискетах, то дискеты не HDD, они ж (дискеты) портятся! Как обходить царапины? Какой механизм фрагментаци? Дата создания? Права доступа? Каталоги? Изменение формата? Длинные имена? Большой размер?

Поздно. Поезд давно ушел. Сейчас russian spectrum = spectrum + tr-dos


Если смотреть с точки зрения совместимости с TR-DOS, то DirSys на 100% удовлетворяла нужду в каталогах (которые по большому счёту большинством пользователей не очень нужны по причине слобости базы - именно файловой системы TR-DOS).
Нафиг огород городить? Хотите работать со старыми программами - используйте TR-DOS базовую файловую систему, на крайний случай -DirSys.

А давай теперь медленно перечитай самое первое сообщение этой ветки, в нем как-раз и было написано чем не устраивает DirSys и зачем "огород городится".


Хотите работать комфортно - берите другую систему, где всё учтено.

Какую другую? Где на спектруме другие системы которые я могу с легкостью взять и использовать вместо TR-DOS'а? Разве что IS-DOS приблизилась к званию конкурента TR-DOS (а там и каталоги и фрагментация и bad-сектора есть и большие диски), но все равно не смогла побороть.

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

A praktiчески с такими файлами нельзя будет работать в ZXASM и многих других программах, которые ищут запись в каталоге ПО ИМЕНИ.

fk0
21.02.2005, 18:05
ок. В случае DirSys'а потребуется изыскать дополнительных 512(1280) байт в памяти для хранения структуры каталогов, найти место для громоздкой процедуры рассчета CRC. В случае каталогов в отдельном файле опять-таки нужно найти место в памяти для его загрузки. В случае TRDIR дополнительного места не потребуется, то есть интегрировать ее проще всего.


Ну не адо никаких громоздких, процедура подсчёта CRC занимает
пару десятков байт.



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


Это значит /гарантированно/ нарваться на несовместимость с другими программами,
с тем же DIRSYS.



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

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


4)В КАТАЛОГЕ !!!

Что мешает в каталоге создавать файлы 0-й длины, и таким образом отделять разные коллекции файлов друг от друга. Во времена zxnet, так на BBS файлы
лежали, было очень удобно. Ещё более удобно, что никакой спец-поддержки
от софта не нужно, такие "каталоги" видны в любом коммандере. Единственный существенный недостаток -- уровень вложенности "каталогов" <= 1.

GriV
21.02.2005, 18:44
была очень неплохая система, вообще то говоря и с большим запасом на будущее, другое дело что маркетологи Iskra-soft очень сглупили хорошо и такую перспективную систему загубили.
Хотя, вообще то говоря, я не рассматриваю is-dos как систему комфортную, но вообще говоря она на 95% удовлетворяла (если не считать её сложности) потребности того времени.

GriV
21.02.2005, 18:47
убрать недостатки проектирумеой пока ещё системы
Оставлять в который раз совместимость с TR-DOS - опять оставить всё на месте

key-jee
22.02.2005, 05:23
4)В КАТАЛОГЕ !!!Вообще-то, это и есть пункт 3.. Прочти ветку с самого начала чтоли :wink:

Spectre
22.02.2005, 12:40
Сразу чувствуется приход маститого фидошника. :) И сразу чувствуется стиль Кирилла Фролова: не читать всю ветку с начала, высказывать свое мнение не взирая на то что было сказано другими. ;)


Ну не адо никаких громоздких, процедура подсчёта CRC занимает пару десятков байт.

Мистер Фролов никогда не видел описания DirSys? А я между прочим перед началом этой темы пытался внедрить DirSys в Quick Commander и неплохо преуспел в деле оптимизации процедуры подсчета CRC. Но вот оригинал, далеко не 20 байт размеру:


CRC PUSH HL
INC DE
LD BC,#0000
CRC1 PUSH DE
LD A,C
XOR (HL)
LD E,A
PUSH BC
PUSH HL
LD BC,#0000
LD D,#08
CRC2 PUSH BC
LD A,C
RRA
LD A,B
RRA
LD B,A
LD A,C
RRA
LD C,A
POP HL
LD A,E
XOR L
AND 1
JR Z,CRC3
LD A,B
XOR #A0
LD B,A
LD A,C
XOR #01
LD C,A
CRC3 LD A,E
RRCA
AND #7F
LD E,A
DEC D
JR NZ,CRC2
POP HL
POP DE
LD A,D
XOR C
LD C,A
LD A,E
XOR B
LD B,A
INC HL
POP DE
LD A,H
CP D
JR NZ,CRC1
LD A,L
CP E
JR NZ,CRC1
DEC DE
POP HL
RET



Это значит /гарантированно/ нарваться на несовместимость с другими программами,

Список программ в студию. Я думаю он будет очень короткий.


с тем же DIRSYS.

Могу приложить к сообщению описание DirSys'а, тогда подобных заявлений станет гораздо меньше. DirSys НЕ ИСПОЛЬЗУЕТ 8-ой сектор для своих записей.

4)В КАТАЛОГЕ !!!

Гениально. А мы 5 страниц тут про что рассуждаем?


Что мешает в каталоге создавать файлы 0-й длины, и таким образом отделять разные коллекции файлов друг от друга. Во времена zxnet, так на BBS файлы
лежали, было очень удобно. Ещё более удобно, что никакой спец-поддержки
от софта не нужно, такие "каталоги" видны в любом коммандере. Единственный существенный недостаток -- уровень вложенности "каталогов" <= 1.

Как мне перенести файл из одного такого каталога в другой? Как мне собрать 3 файла разнесенных по всему диску в один такой каталог без физического копирования?

Spectre
22.02.2005, 12:48
И вообще ветка для этого и устраивается для того чтобы за счёт (не)здоровой критики убрать недостатки проектирумеой пока ещё системыОставлять в который раз совместимость с TR-DOS - опять оставить всё на месте

Все только за. Но причем к системе каталогов в TR-DOS недостатки самого TR-DOS'а? Это несколько другая тема. Здесь пока система каталогов в проекте хотелось бы обсуждать именно ее.

Vitamin
22.02.2005, 19:35
Формат даты (полубайтами): день+месяц и мл.байт+ст.байт года, берется из CMOS часов.
получается, система будет работать только 2 недели из месяца? :)
почему бы не использовать еще 2 байта- расположение файла, все равно оно не имеет смысла для каталогов- файлов нулевой длины

Spectre
22.02.2005, 22:14
получается, система будет работать только 2 недели из месяца? :)

Гм, да. :) Действительно, не учел.


почему бы не использовать еще 2 байта- расположение файла, все равно оно не имеет смысла для каталогов- файлов нулевой длины

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

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

Тогда от даты придется точно отказаться и у нас остается 1 неиспользуемый байт.

key-jee
23.02.2005, 04:08
Мне, как и многим другим наверное, тоже кажется, что трдос не даст развиться спеку в плане железа, ибо максимальный размер диска при всём желании не превысит 1 метра (256 дорог по 16 секторов), а это в наше время - мало, винты уже не на 40М в максимуме, правда и спектрум софта не столь много, но всё-таки хочется большего.. Поэтому мне кажется, что трдос - всё-таки не идеален :wink: для файловой системы, Проблема только в том, что софта под трдос 99% от всего софта имеющегося на спеке..

jtn
23.02.2005, 18:32
Проблема только в том, что софта под трдос 99% от всего софта имеющегося на спеке..
насчет 99% ты сильно загнул, TRDOS стал популярен уже ближе к середине 90х (у буржуев он не был популярен никогда), а каков % от всего софта выпущено к до
92-93 годов и после?

key-jee
23.02.2005, 21:28
насчет 99% ты сильно загнул, TRDOS стал популярен уже ближе к середине 90х (у буржуев он не был популярен никогда), а каков % от всего софта выпущено к до
92-93 годов и после?Суть в том, что тот софт, который мы привыкли использовать, идёт под трдос, и нужно перенести весь этот софт под новую ФС..

jtn
24.02.2005, 05:46
Суть в том, что тот софт, который мы привыкли использовать, идёт под трдос, и нужно перенести весь этот софт под новую ФС..
вот если только в этом посте поменять "мы" на "я", а в предыдущем "весь" на "которым я пользуюсь", тогда все станет на свои места.

p.s. мне вот например нравится игрушки из tzx'ов грузить...

CityAceE
24.02.2005, 13:38
А между тем ещё одна софтина поддержала DirSys! :p

fk0
24.02.2005, 20:42
Мистер Фролов никогда не видел описания DirSys? А я между прочим перед началом этой темы пытался внедрить DirSys в Quick Commander и неплохо преуспел в деле оптимизации процедуры подсчета CRC. Но вот оригинал, далеко не 20 байт размеру:


[...ужасы поскипаны...]

И что из того следует? Что некоторые сценеры уступают в качестве генерации кода C-компилятору?
Библиотечная crc16 занимает не больше 30 байт и там есть возможности для оптимизации.
Кроме того, "обращённый" слева на право алгоритм требует заведомо больших ресурсов, на любой
машине. Поэтому все классические алгоритмы, используемые в модемах, коммуникационных протоколах,
и даже в контроллере спековского дисковода, используют сдвиг влево -- команда add в любой ЭВМ..
Кроме того, существует множество других контрольных кодов, применение CRC в данном случае
не оправдано.



Список программ в студию. Я думаю он будет очень короткий.


Проблема в том, что в общем случае неизвестно, что там каждая программа в "служебных" секторах
делает. И вторая существенная проблема -- scl.



Могу приложить к сообщению описание DirSys'а, тогда подобных заявлений станет гораздо меньше. DirSys НЕ ИСПОЛЬЗУЕТ 8-ой сектор для своих записей.


Тем для него хуже. Ибо 8 сектор чаще сохраняется в целостности.



Как мне перенести файл из одного такого каталога в другой? Как мне собрать 3 файла разнесенных по всему диску в один такой каталог без физического копирования?

Никак. Перенос файлов редкая операция, можно и скопировать. Зато предельно простое и совместимое решение.