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

[CityAceE]

а такую систему не угробить никакими мувами.

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

[elf/2]

пара идей/комментариев:

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

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

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

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

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

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

[key-jee]

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

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

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

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

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

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

[elf/2]

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

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

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

странно, процедура подсчета crc много места занять не должна. а для ленивых кодеров ее надо положить в дистрибутив коммандера и/или описание формтата системы.
imho, наличие/отсутсвие необходимости подсчета crc не влияет на наличие/остутсвие поддержки системы в новом софте.

[key-jee]

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

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

[key-jee]

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

[CityAceE]

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

Великолепная идея! Возьму-ка я её на вооружение в следующей версии DirSys. Пока правда не могу до конца сообразить как восстановить сортировку по каталогам после стороннего MOVE, но нутром чую, что это более чем реально! Конечно, если сделать DEL и следом MOVE в стороннем коммандере, то сортировку на восстановить, а вот если только MOVE, то можно. Это лучше чем ничего!

[elf/2]

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

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

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

[elf/2]

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

можно ограничить число файлов+каталогов до 120. или положить эту таблицу в 10й сектор. если ее убъет migic - ну и хрен с ней (для работы системы она не является критичной, ее всегда можно посчитать заново)

[elf/2]

Великолепная идея! Возьму-ка я её на вооружение в следующей версии DirSys. Пока правда не могу до конца сообразить как восстановить сортировку по каталогам после стороннего MOVE, но нутром чую, что это более чем реально! Конечно, если сделать DEL и следом MOVE в стороннем коммандере, то сортировку на восстановить, а вот если только MOVE, то можно. Это лучше чем ничего!

дык!
только тебе целый дополнительный сектор понадобиться
del+move - нужна еще одна таблица (1-2 байта на файл [crc заголовка])

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

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

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