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

[CityAceE]

DirSys - это система каталогов, подробно описанная и документированная. На Спектруме она в полной мере поддержана коммандером TR-DOS Navigator. Но в нём действительно всё настолько переплетено и запутано, что вытащить отдельные функции для работы с каталогами не представляется возможным. Гораздо проще всё написать самому с нуля. Тем более, что это не так сложно.

[Advertiser]

[elf/2]

Чем дальше, тем больше мне нравится идея с датами. И я убеждён, что её просто необходимо реализовать!

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

[CityAceE]

Да, всё верно. Но тем не менее надо же с чего-то начать. Я попробую начать с модификации TRDN, а там, глядишь, и народ потянется. Хотя, учитывая суровую реальность, вряд ли.

[Alexandr Medvedev]

В крайнем случае дату корневого каталога можно хранить где-то в 9-м секторе - там много свободного места!

Как бы не так. Назови хоть один байт. Всё там занято.
00...DF дескрипторы файлов
E0 байт 00 (признак окончания каталога)
E1...F4 служебные байты
F5...FF имя диска.
Ну и где свободные байты?

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

Нужна ПОЛНАЯ СОВМЕСТИМОСТЬ, не требующая изменеия кода существущих программ.

Чтобы система стала максимально полезной нужно как минимум включить её поддержку в TRDN и в плагин для FAR'а.

По поводу плагина для FAR не вижу смысла делать поддержку DirSys который не совместим со старым.
Старые версии и так нигде не испозуются, а тут ещё новые придумали. Путаница да и только.
Если уж что и делать то только СОВМЕСТИМОЕ со старыми версиями.

Идея вобщем-то неплохая, но вот совместимость терять нельзя.

Добавлено через 7 минут
Чтобы не терять совместимоть базу с датами можно хранить например в отдельном файле с фиксированным именем. В таком случае совместимость сохраняется. Как и прежде такая конструкция будет бояться только команды TR DOS MOVE.

[Grand]

Диапазон дат лучше сделать 1979-2043

Я бы предпочёл начать отсчёт с 1980-го года. Вроде бы на PC именно с этой даты отсчёт шёл. А можно и с 1982 - года рождения Спектрума.

Я не настаиваю, но существуют платформы, появившиеся раньше iBM PC, и, теоритически, файл с такой платформы может быть перенесён и на Спектрум.

Должна быть предусмотрена ситуация, когда дата объекта отсутствует...

В этом случае скорее всего в области дат будут нули. И если это будет так, то можно принудительно назначать дату 01.01.1980, ну или, например, 18.04.1982 - ДР Спектрума.

Нет-нет! Именно именно без даты! Такая возможность есть в операционных системах на ДВК. И там она сейчас актуальна: диапазон дат был до 1999 года.

Наверное секунды секунды действительно лишние...

А я всё же думаю, что не лишние...

И еще: так ли нужна дата создания каталога?

Обязательно нужна!...

"Ну, тут мы с вами не совпадаем..."

Всё, что потребуется - это изменить номер системы с 1.00, на, скажем, 1.10. Это будет говорить софту, что можно работать не более чем с 64-мя каталогами и о необходимости искать даты в последних трёх секторах.

А почему не 1.01 - ведь изменения структуры минимальны?

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

Я предлагал для начала обсудить хотя бы структуру "пакета рабочих процедур". Когда будет ясно, как это должно выглядеть в общем виде, можно будет приступить и к написанию.

http://www.zx.pk.ru/showthread.php?p=98562#post98562


Назначение битов в байтах даты предлагаю таким:

Самый младший байт                               Самый старший байт
b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7
b0b1b2b3b4b5b0b1 b2b3b4b5b0b1b2b3 b4b0b1b2b3b4b0b1 b2b3b0b1b2b3b4b5
\--секунды-/\--минуты---/\---часы--/\--день--/\--мес--/\---год---/

Такое решение позволит легко производить сортировку по возрастанию или убыванию даты.

[CityAceE]

Как бы не так. Назови хоть один байт. Всё там занято.
00...DF дескрипторы файлов
E0 байт 00 (признак окончания каталога)
E1...F4 служебные байты
F5...FF имя диска.
Ну и где свободные байты?

У меня в голове всегда была примерно такая информация. Цитирую книгу Юрия Поморцева "TR-DOS для профессионалов и любителей":

Системную информацию о дискете содержит 8-й сектор нулевой дорожки, точнее, конец этого сектора, начиная с 225-го байта.

ИМЯ
АДРЕС
НАЗНАЧЕНИЕ

BUFF_ADR
0
#00
#5025
Начало системного сектора, загруженного в динамически выделяемый буфер для дисковых операций.

DCU_SEC
223
224
#DF
Слово. Содержит число секторов на диске, расформатированном при помощи DCU
(вначале равно значению в #E5). На диске расформатированом TR-DOS равно 0.

FR_S_NEXT
225
#E1
#5E06
Байт. Номер следующего свободного сектора. Инициализируется нулем.

FR_T_NEXT
226
#E2
#5E07
Байт. Номер следующей свободной дорожки. Инициализируется единицей.

TYPE DISC
227
#E3
#5E08
Байт. Тип дискеты:
#16 - 80 track, 2 side
#17 - 40 track, 2 side
#18 - 80 track, 1 side
#19 - 40 track, 1 side

N_FILES
228
#E4
#5E09
Байт. Количество файлов на диске, включая удаленные. Инициализируется нулем.

N_FRE_SEC
229
230
#E5
#5E0A
Слово. Количество свободных секторов. Инициализируется в зависимости от типа диска:
#09F0 - 80 track, 2 side
#04F0 - 40 track, 2 side
#04F0 - 80 track, 1 side
#0270 - 40 track, 1 side
При форматировании программой DCU на максимальное число дорожек:
#0A70 - 84 track, 2 side
#0AB0 - 86 track, 2 side

MAIN_BYTE
231
#E7
#5E0C
Байт. Количество секторов на дорожке. Должно быть #10, иначе диск признается неформатированным.

ZERO
232
#E8
Два байта нулей.

BLANK9
234
#EA
9 байтов пробелов (код #20).

ZERO
243
#F3
1 нулевой байт.

N_DEL_FIL
244
#F4
#5E19
Байт. Количество удаленных файлов. Инициализируется нулем.

DISC_TITL
245
#F5
#5E1A
Поле из 8 байт. Имя диска после форматирования.

ZERO
253
#FD
3 байта нулей. Конец главного сектора.

Почти всё совпадает с тем, что ты пишешь, кроме вот этого:

00...DF дескрипторы файлов

Что такое дескрипторы файлов?

Нужна ПОЛНАЯ СОВМЕСТИМОСТЬ, не требующая изменеия кода существущих программ.

Абсолютно с тобой согласен! Но давай разберёмся с предлагаемым мной вариантом.

Для начала давай вспомним, а какими программами DirSys поддержана? Во-первых, это TRDN, а во-вторых, это плагин для FAR'а. Именно эти две программы поддерживают систему в полной мере, то есть могут копировать файлы, создавать каталоги и, самое главное, делать уплотнение диска. Остальной немногочисленный список программ позволяет только видеть каталоги либо, самое максимальное, записывать в существующие каталоги файлы. Ни одна программа, кроме двух перечисленных, не умеет уплотнять диск с учётом наличия DirSys, а между тем именно уплотнение является тем критичным моментом, который может порушить систему и может повлиять на совместимость. Соответственно, если оперативно доработать эти две программы, то совместимость не пострадает.

Второй момент, это ограничение на 64 каталога на диске. Но и здесь не вижу проблем! Во-первых, есть дескриптор системы с её номером. Если номер версии равен 1.00, то работаем со 128-ю каталогами и забываем про даты. Если же 1.10, то делаем ограничение на 64 каталога и работаем с датами. И опять же повторюсь, я убеждён, что если кто-то реально и использует систему каталогов, то скорее всего не найдётся ни одного диска на котором число каталогов превышало бы цифру 64. А по сему вопрос отпадает сам собой.

По поводу плагина для FAR не вижу смысла делать поддержку DirSys который не совместим со старым.
Старые версии и так нигде не испозуются, а тут ещё новые придумали. Путаница да и только.
Если уж что и делать то только СОВМЕСТИМОЕ со старыми версиями.

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

Идея вобщем-то неплохая, но вот совместимость терять нельзя.

Да идея просто отличная! Даты - это последнее чего не хватало файловой системе TR-DOS для полноценного перегона из iS-DOS или MS-DOS. Трехсимвольные расширения есть, каталоги есть, дело за датами! Но я, конечно же, не беру во внимание ограничение на размер файлов в 255 секторов и другие ограничения (128 файлов, только непрерывные файлы и др.)

Чтобы не терять совместимость базу с датами можно хранить например в отдельном файле с фиксированным именем. В таком случае совместимость сохраняется. Как и прежде такая конструкция будет бояться только команды TR DOS MOVE.

Не нравится мне идея с отдельным файлом под это дело. Уже неоднократно предлагалось и саму DirSys посадить в отдельный файл, но я лично против такого подхода. Как ты сам сказал, системой практически никто не пользуется. Лишний файл явно будет мешаться, его будут удалять либо наоборот переписывать вместе с остальными файлами, там самым вводя, поддерживающий DirSys софт, в заблуждение. А когда система целиком и полностью живёт на нулевой дорожке, то про её существование никто даже и не догадывается. Если человек не пользуется системой и "грохнет" её по незнанию, то для этого человека не произойдёт ничего страшного. Но, скорее всего, система будет тихонько себе жить на нулевом треке. Главное - не уплотнять диск!

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

[James DiGreze]

Назначение битов в байтах даты предлагаю таким:

Самый младший байт                               Самый старший байт
b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7
b0b1b2b3b4b5b0b1 b2b3b4b5b0b1b2b3 b4b0b1b2b3b4b0b1 b2b3b0b1b2b3b4b5
\--секунды-/\--минуты---/\---часы--/\--день--/\--мес--/\---год---/

Такое решение позволит легко производить сортировку по возрастанию или убыванию даты.

Тогда уж лучше наоборот: год-месяц-день-час-минута-секунда. Год в данном случае - старший разряд числа, а секунда - младший. Тогда и сортировку можно будет сделать хоть методом пузырька.

[CityAceE]

А почему не 1.01 - ведь изменения структуры минимальны?

Всё же ограничение на 64 каталога и, самое главное, ввод поддержки дат заслуживают более глобального увеличения версии.

Тогда уж лучше наоборот: год-месяц-день-час-минута-секунда.

Grand так и написал, просто запись сделал непривычно - шиворот на выворот

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

Нет-нет! Именно именно без даты! Такая возможность есть в операционных системах на ДВК. И там она сейчас актуальна: диапазон дат был до 1999 года.

Однако чаще всего нам придётся иметь дело с FAT, NTFS, файловой системой iS-DOS. Везде присутствуют даты! Предположим, что плагин для FAR всё же доработали и он понимает даты. Также предположим, что мы имеем диск с доработанной системой DirSys, на котором есть каталог TEXT, в котором лежит несколько файлов *.txt. На самом каталоге и файлах установлен признак "без даты". Как должен поступать плагин при переводе этого каталога и файлов из TR-DOS в FAT (NTFS)? Назначить текущую дату? А при обратном перегоне уже текущая дата будет записана на диск? Тогда не совсем понятен смысл признака "без даты". На мой взгляд это лишнее. Если даты нет, значит её надо назначить принудительно: либо дефолтовой (например, 01.01.1980), либо текущей.

[Costa]

Не нравится мне идея с отдельным файлом под это дело. Уже неоднократно предлагалось и саму DirSys посадить в отдельный файл, но я лично против такого подхода. Как ты сам сказал, системой практически никто не пользуется. Лишний файл явно будет мешаться, его будут удалять либо наоборот переписывать вместе с остальными файлами, там самым вводя, поддерживающий DirSys софт, в заблуждение.

А если сделать системный файл невидимый или ввести атрибуты по типу read only/скрытый/архивный ?
Как раз больше вероятности убить систему если все свободные ектора задействованы и кто то по незнанию или невнимательности заюзает программу которая туда пишет тотже скорпион.
Отдельный файл ещё чем хорош, вот появятся ещё какие мысли по дальнейшему усовершенствованию а места то на 0 дорожке больше нету.

Однако чаще всего нам придётся иметь дело с FAT, NTFS, файловой системой iS-DOS. Везде присутствуют даты! Предположим, что плагин для FAR всё же доработали и он понимает даты. Также предположим, что мы имеем диск с доработанной системой DirSys, на котором есть каталог TEXT, в котором лежит несколько файлов *.txt. На самом каталоге и файлах установлен признак "без даты". Как должен поступать плагин при переводе этого каталога и файлов из TR-DOS в FAT (NTFS)? Назначить текущую дату? А при обратном перегоне уже текущая дата будет записана на диск? Тогда не совсем понятен смысл признака "без даты". На мой взгляд это лишнее. Если даты нет, значит её надо назначить принудительно: либо дефолтовой (например, 01.01.1980), либо текущей.

Если даты нет то имеем вид --:--:-- --/--/--

[boo_boo]

Всё, что потребуется - это изменить номер системы с 1.00, на, скажем, 1.10. Это будет говорить софту, что можно работать не более чем с 64-мя каталогами и о необходимости искать даты в последних трёх секторах.

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

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