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

[Alexandr Medvedev]

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

очень метко сказал, именно по этой причине я и не вижу смысла вводить даты

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

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

Недокументированная особенность такая, в TR DOS можно не 128 а 142 файла хранить.

[Grand]

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

Да. Потому-что другого не дано: это недоработка системы MS-DOS; мы же можем и должны сделать правильно. Впрочем, в W98, в "свойствах файла" иногда появляется "Изменён: неизвестно", значит кое-что там всё-таки предусмотрели.
Представим другую ситуацию. У нас есть Спектрум-совместимый компьютер без интерфейса CMOS-часов и TR-DOS Navigator с новой Directory System, поддерживающей даты. Мы берём готовый диск TR-DOS без DirSys с целью рассортировать файлы. Создаём каталог, переносим туда файлы, и что увидим? У всех файлов одинаковая дата: "01.01.80"!

Тогда не совсем понятен смысл признака "без даты".

"Без даты" (или "пустая дата") - это как "пустой стринг" в BASIC: LET a$="" Как-бы в стринге ничего нет, но сам он есть!

Если даты нет, значит её надо назначить принудительно: либо дефолтовой (например, 01.01.1980), либо текущей.

Программы, записывающие диски MS-DOS на Спектруме (TRMSHOB, Domen OS) так и делают, и это выглядит глупо: недоработка MS-DOS, как я сказал.

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

Или вообще чистую строчку.

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

Недокументированная особенность такая, в TR DOS можно не 128 а 142 файла хранить.

Directory System её не использует, и, надеюсь, никогда не будет . Каталоги нужнее лишних файлов. Но это моё мнение.
Однако, хотелось бы узнать, а есть ли софт, использующий эту "недокументированную особенность"?

[Alexandr Medvedev]

Directory System её не использует, и, надеюсь, никогда не будет . Каталоги нужнее лишних файлов. Но это моё мнение.

Да почему не будет? Что мешает-то?
Лишние файлы храняться в начале системного сектора а DirSys храниться ПОСЛЕ системного сектора. Утверждение о том что каталоги нужнее лишних файлов мне не понятно. Они друг другу абсолютно не мешают.
В плагине к FAR на дисках в DirSys файлы после 128-го всегда относятся в корневому каталогу, предлагаю так-же сделать и в TRDN, для полной совместимости.
По поводу дат не совсем понятно за что эти даты будут отвечать. В FAT и NTFS есть даты содания, модификации и последнего доступа к файлу, а что планируется в DirDys?

[Grand]

В FAT и NTFS есть даты содания, модификации и последнего доступа к файлу, а что планируется в DirDys?

Дату последнего изменения для файлов и создания для каталогов, как я полагаю. Другое в однозадачной ОС, как считаю я, - лишнее.
В общем-то, для TR-DOS дата создания и дата изменения, в целом, одно и тоже, поскольку, в большинстве случаев, прикладные программы записывают новый файл с изменениями, а старый удаляют.

Лишние файлы храняться в начале системного сектора а DirSys храниться ПОСЛЕ системного сектора. Утверждение о том что каталоги нужнее лишних файлов мне не понятно. Они друг другу абсолютно не мешают.

Опять-таки моё мнение, но как-то непрофессионально это выглядит... DirDys - это прозрачная надстройка: софт, незнающий о ее существовании будет работать без ошибок со стандартным каталогом TR-DOS, а со 142-я файлами конфликт почти гарантирован. Я никогда не решусь хранить более 128-и файлов с таким "дополнением".
Кроме того, некоторые программы проверяют целостность информации нулевой дорожки, и естественно выдадут ошибку. Такую проверку мы планиоуем сделать в будущих версиях TR-DOS Navigator'а.

[Grand]

DirSys в своём максимуме имеет размер 1398 байт и занимает при этом 6 секторов.

У меня результат другой: 1666 байтов, или чуть больше 6,5 секторов.

Однако, ошибся и я.
1665 байтов. В последнем секторе остаётся 127 неиспользуемых байтов.

[GriV]

Проблема большей частью имхо обстоит не в том, как вводить даты а в том как их хранить чтобы программы на соседних платформах не ошибались и можно было использовать имеющийся инструментарий
то есть проще говоря надо писать не только на реальный диск но и на диск TRD формата который не может содержать дополнительных секторов/дорожек и прочих извратов которые на реале вполне даже возможны.
Погрязли в эмулировании называется %)
Вариант использования последней/предпоследней дорожки не устраивает?

[Advertiser]

[CityAceE]

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

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

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

Разбираясь с форматом хранения отгрузок Nintendo GameCube наткнулся на интересный метод хранения даты (его встречал и ранее, но забыл). В четырёх байтах хранится количество секунд, которое прошло начиная с определённой даты. То есть в 4 байта умещается диапазон в 136 лет и сколько-то там дней! Весьма неплохо... Вот только процедура перевода секунд в дату займёт прилично места.

[Alexandr Medvedev]

В четырёх байтах хранится количество секунд, которое прошло начиная с определённой даты.

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

// Number of 100 nanosecond units from 01.01.1601 to 01.01.1970
#define EPOCH_BIAS    _i64(116444736000000000)

void WINAPI UnixTimeToFileTime( DWORD time, FILETIME * ft )
{
  *(__int64*)ft = EPOCH_BIAS + (__int64)time * _i64(10000000);
}

[Grand]

В четырёх байтах хранится количество секунд...

Идея интересная. Хочется, чтобы была написана процедура на ассемблере Z80 чтобы оценить ее быстродействие на реальном ZX.

[CityAceE]

По большому счёту, это получается нечто типа программы вечного календаря. Наверняка эта задача уже решалась для Z80 и не раз.