Вид для печати
DirSys - это система каталогов, подробно описанная и документированная. На Спектруме она в полной мере поддержана коммандером TR-DOS Navigator. Но в нём действительно всё настолько переплетено и запутано, что вытащить отдельные функции для работы с каталогами не представляется возможным. Гораздо проще всё написать самому с нуля. Тем более, что это не так сложно.
позволю себе добавить ложку дегтя:Цитата:
Сообщение от CityAceE
для того чтобы идея с датами начала работать необходима поддержка расширения DirSys'а наиболее популярными редакторами, поскольку дата файла должна меняться при каждой его модификации. боюсь что вероятность появления подобной поддержки стремиться к нулю :(
Да, всё верно. Но тем не менее надо же с чего-то начать. Я попробую начать с модификации TRDN, а там, глядишь, и народ потянется. Хотя, учитывая суровую реальность, вряд ли.
Как бы не так. Назови хоть один байт. Всё там занято.Цитата:
Сообщение от CityAceE
00...DF дескрипторы файлов
E0 байт 00 (признак окончания каталога)
E1...F4 служебные байты
F5...FF имя диска.
Ну и где свободные байты?
Нужна ПОЛНАЯ СОВМЕСТИМОСТЬ, не требующая изменеия кода существущих программ.Цитата:
Сообщение от Grand
По поводу плагина для FAR не вижу смысла делать поддержку DirSys который не совместим со старым.Цитата:
Сообщение от CityAceE
Старые версии и так нигде не испозуются, а тут ещё новые придумали. Путаница да и только.
Если уж что и делать то только СОВМЕСТИМОЕ со старыми версиями.
Идея вобщем-то неплохая, но вот совместимость терять нельзя.
Добавлено через 7 минут
Чтобы не терять совместимоть базу с датами можно хранить например в отдельном файле с фиксированным именем. В таком случае совместимость сохраняется. Как и прежде такая конструкция будет бояться только команды TR DOS MOVE.
Я не настаиваю, но существуют платформы, появившиеся раньше iBM PC, и, теоритически, файл с такой платформы может быть перенесён и на Спектрум.Цитата:
Сообщение от CityAceE
Нет-нет! Именно именно без даты! Такая возможность есть в операционных системах на ДВК. И там она сейчас актуальна: диапазон дат был до 1999 года.Цитата:
Сообщение от CityAceE
Цитата:
Сообщение от CityAceE
"Ну, тут мы с вами не совпадаем..." :)Цитата:
Сообщение от CityAceE
А почему не 1.01 - ведь изменения структуры минимальны?Цитата:
Сообщение от CityAceE
Я предлагал для начала обсудить хотя бы структуру "пакета рабочих процедур". Когда будет ясно, как это должно выглядеть в общем виде, можно будет приступить и к написанию.Цитата:
Сообщение от Nomy Graphics
http://www.zx.pk.ru/showthread.php?p=98562#post98562
Назначение битов в байтах даты предлагаю таким:
Такое решение позволит легко производить сортировку по возрастанию или убыванию даты.Код:Самый младший байт Самый старший байт
b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7
b0b1b2b3b4b5b0b1 b2b3b4b5b0b1b2b3 b4b0b1b2b3b4b0b1 b2b3b0b1b2b3b4b5
\--секунды-/\--минуты---/\---часы--/\--день--/\--мес--/\---год---/
У меня в голове всегда была примерно такая информация. Цитирую книгу Юрия Поморцева "TR-DOS для профессионалов и любителей":Цитата:
Сообщение от Alexandr Medvedev
Цитата:
Системную информацию о дискете содержит 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 дескрипторы файлов
Абсолютно с тобой согласен! Но давай разберёмся с предлагаемым мной вариантом.Цитата:
Сообщение от Alexandr Medvedev
Для начала давай вспомним, а какими программами DirSys поддержана? Во-первых, это TRDN, а во-вторых, это плагин для FAR'а. Именно эти две программы поддерживают систему в полной мере, то есть могут копировать файлы, создавать каталоги и, самое главное, делать уплотнение диска. Остальной немногочисленный список программ позволяет только видеть каталоги либо, самое максимальное, записывать в существующие каталоги файлы. Ни одна программа, кроме двух перечисленных, не умеет уплотнять диск с учётом наличия DirSys, а между тем именно уплотнение является тем критичным моментом, который может порушить систему и может повлиять на совместимость. Соответственно, если оперативно доработать эти две программы, то совместимость не пострадает.
Второй момент, это ограничение на 64 каталога на диске. Но и здесь не вижу проблем! Во-первых, есть дескриптор системы с её номером. Если номер версии равен 1.00, то работаем со 128-ю каталогами и забываем про даты. Если же 1.10, то делаем ограничение на 64 каталога и работаем с датами. И опять же повторюсь, я убеждён, что если кто-то реально и использует систему каталогов, то скорее всего не найдётся ни одного диска на котором число каталогов превышало бы цифру 64. А по сему вопрос отпадает сам собой.
Я попытался донести свои мысли, хотелось бы выслушать контраргументы.Цитата:
Сообщение от Alexandr Medvedev
Да идея просто отличная! :) Даты - это последнее чего не хватало файловой системе TR-DOS для полноценного перегона из iS-DOS или MS-DOS. Трехсимвольные расширения есть, каталоги есть, дело за датами! Но я, конечно же, не беру во внимание ограничение на размер файлов в 255 секторов и другие ограничения (128 файлов, только непрерывные файлы и др.)Цитата:
Сообщение от Alexandr Medvedev
Не нравится мне идея с отдельным файлом под это дело. Уже неоднократно предлагалось и саму DirSys посадить в отдельный файл, но я лично против такого подхода. Как ты сам сказал, системой практически никто не пользуется. Лишний файл явно будет мешаться, его будут удалять либо наоборот переписывать вместе с остальными файлами, там самым вводя, поддерживающий DirSys софт, в заблуждение. А когда система целиком и полностью живёт на нулевой дорожке, то про её существование никто даже и не догадывается. Если человек не пользуется системой и "грохнет" её по незнанию, то для этого человека не произойдёт ничего страшного. Но, скорее всего, система будет тихонько себе жить на нулевом треке. Главное - не уплотнять диск!Цитата:
Сообщение от Alexandr Medvedev
В общем, надо делать. Тем более, чего уж греха таить, подавляющее большинство пользователей используют эмуляторы, а соответственно имеют часы реального времени. Я попробую доработать под это дело TRDN и проверить всё на практике.
Тогда уж лучше наоборот: год-месяц-день-час-минута-секунда. Год в данном случае - старший разряд числа, а секунда - младший. Тогда и сортировку можно будет сделать хоть методом пузырька. ;)Цитата:
Сообщение от Grand
Всё же ограничение на 64 каталога и, самое главное, ввод поддержки дат заслуживают более глобального увеличения версии.Цитата:
Сообщение от Grand
Grand так и написал, просто запись сделал непривычно - шиворот на выворот :)Цитата:
Сообщение от James DiGreze
Добавлено через 13 минут
Однако чаще всего нам придётся иметь дело с FAT, NTFS, файловой системой iS-DOS. Везде присутствуют даты! Предположим, что плагин для FAR всё же доработали и он понимает даты. Также предположим, что мы имеем диск с доработанной системой DirSys, на котором есть каталог TEXT, в котором лежит несколько файлов *.txt. На самом каталоге и файлах установлен признак "без даты". Как должен поступать плагин при переводе этого каталога и файлов из TR-DOS в FAT (NTFS)? Назначить текущую дату? А при обратном перегоне уже текущая дата будет записана на диск? Тогда не совсем понятен смысл признака "без даты". На мой взгляд это лишнее. Если даты нет, значит её надо назначить принудительно: либо дефолтовой (например, 01.01.1980), либо текущей.Цитата:
Сообщение от Grand
А если сделать системный файл невидимый или ввести атрибуты по типу read only/скрытый/архивный ?Цитата:
Сообщение от CityAceE
Как раз больше вероятности убить систему если все свободные ектора задействованы и кто то по незнанию или невнимательности заюзает программу которая туда пишет тотже скорпион.
Отдельный файл ещё чем хорош, вот появятся ещё какие мысли по дальнейшему усовершенствованию а места то на 0 дорожке больше нету.
Если даты нет то имеем вид --:--:-- --/--/--Цитата:
Сообщение от CityAceE
очень грустно, когда софт должен ориентироваться по номеру версии: код превращается в капусту из проверок версий, причем программеру еще надо будет держать в голове или под рукой список фич, той или иной версией поддерживаемых. жуть :)Цитата:
Сообщение от CityAceE
IMNSHO такие вещи, как кол-во каталогов и поддержка дополнительных фич, должны быть непосредственно указаны в дескрипторе системы.
еще мысль -- а зачем именно даты, причем в обязательном порядке для каждого файла/каталога? почему бы не сделать поддержку абстрактных "тэгов", то есть полей данных, ассоциированных с файлом/каталогом? тогда, не меняя структуры данных, можно будет хранить хоть даты, хоть права, хоть чертей лысых