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

[Spectre]

Не один раз и не одним человеком предпринимались попытки создать систему каталогов на 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

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

[Advertiser]

[CityAceE]

необходимостью загружать не первые 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]

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

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

[Spectre]

В предложенном варианте мне не нравится как минимум то, что совокупное количество файлов и каталогов не может превышать 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]

Это пока единственный недостаток.

Ну не скажи, единственный...
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]

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

Суть в другом! Ты думаешь о том, каким бы образом запихнуть каталоги в программы, которые отродясь не думали о них. И получается, что это дело идет в ущерб юзеру. Ведь юзера мало волнует что в коммандере места мало - ему нужно удобство. Я когда запланировал совой коммандер сразу делал акцент на каталоги и теперь я могу поддержать практически любую каталоговую систему будь то 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]

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

Это был AlCo со своими журналами, а использовал он DirSys.

[Spectre]

Ну не скажи, единственный...
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]

Не буду тебя цитировать, а то потом никому читать не удобно. Лишь подытожу
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 я всё равно не брошу Завсегда можно написать конвертор из одной системы в другую

[fk0]

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

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

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

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

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

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

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

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