Работа с файловой системой

Kernel architecture questions
  • Поскольку появилась возможность работы с папками на рамдиске, может стоит обсудить дерево каталогов для колибри? Можно создать отдельную ветку. У кого какие предложения?
  • все либы - в папку lib, ресурсы и другие вспомогательные файлы приложений - в etc ...
  • Heavyiron
    willow
    ИМХО такие вещи могут носить рекомендательный характер, потому что не обязательны к исполнению и любой пользователь может использовать такие названия, какие ему нравятся и понятны.
    Но это опять же только ИМХО.
  • Тогда разных папок может появиться очень много. Конечно, рекомендательный характер
  • Речь про структуру папок "по умолчанию" для официального дистрибутива, насколько я понимаю, а не о том, кому какие названия нравятся. И если в официальном дистрибутиве все программы скомпилированы так, чтобы использовать файлы из папки lib, а пользователь переименовал её в bibl, то как уж тут гарантировать работоспособность приложений.
  • mike.dld
    Можно сделать INI файл, где будут прописаны основные пути.
  • 1. Почему только 1024? ИМХО мало, надо хоть подогнать под размер сегмента тогда и сделать 4096 хотя бы.
    Наоборот, это с запасом. Скажем, в Windows требуется, чтобы максимальная длина имени файла не превосходила MAX_PATH = 260 (кстати, на самом деле в NT-семействе можно создать файл с очень длинным именем, причём это даже документировано в описании CreateFile:
    In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\\?\" to the path.
    - проверял, без проблем создаёт, пишет и потом таким же методом можно прочитать. Правда, стандартными средствами (Explorer/Far/TotalCommander) такой файл обработать нельзя, а Explorer и TC его даже удалить не могут! Far может. Впрочем, это к делу не относится. В 9x такие шуточки не пройдут.) В DOS, хотя там и короткие имена, вообще лимит 80 символов. Ограничения в *nix я с ходу не помню, но тоже этого порядка.
    3. Обнуляется только до конца сегмента или вся рабочая память запрошенная под приложение?
    Это одно и то же, приложение размещается в одном сегменте. Новая модель ядра от Serge ещё в действие не вступила, но думаю, там будет обнуляться вся память, за исключением самого файла.
    4. А здесь у меня возникли сомнения, поскольку все процедуры используют для запуска область с адреса 0x90000. Мне кажется, могут возникнуть ситуации, когда еще одно приложение не освободило область, а другое приложение уже запущено - может получиться пересечение данных и все кердык...
    Есть такой мьютекс - application_table_status. Код загрузки приложения должен захватить этот мьютекс и только после этого получит возможность менять системные структуры, к которым можно отнести и область по 0x90000.
    5. Судя по коду fs_execute не учитывает, что размер сектора (физического сектора, а не логического кластера) может быть больше чем 512 байт. Отсюда вопрос, как мне прикручивать запуск файлов с CD к этой процедуре? Писать паралельную процедуру не хочется, да и не экономно получается. Что делать?
    fs_execute читает данные блоками по 0x200 байт. Размер сектора на CD, если не ошибаюсь, 0x800 байт. Размер кластера на HD переменный, но кратен размеру сектора 0x200. Процедура fs_HdExecute.DoRead читает очередной сектор, для чего ей приходится хранить текущий кластер и номер сектора в кластере. Аналогичная процедура для CD должна при каждом 4-м запросе считывать в буфер новый сектор и хранить номер блока в секторе. Буфер лучше использовать по адресу 0x90000, поскольку эта область охраняется вышеупомянутым мьютексом (для другого буфера придётся беспокоиться о сценарии, когда между двумя вызовами .DoRead вызывается, например, функция 70.0 и перезаписывает данные - так что придётся заново считывать этот сектор)
    Ушёл к умным, знающим и культурным людям.
  • Heavyiron
    Поскольку появилась возможность работы с папками на рамдиске,
    В 70-й функции - да, появилась. А вот остальные функции про неё не знают. Можешь попробовать создать на рамдиске папку и зайти туда mfar'ом или systree - забавные результаты (особенно для mfar). Переписывать приложения надо! Я свои - mtdbg,mtappack - переписал. @panel уже тоже модифицирована. А вот остальные...
  • Mario79
    Поправка: можно использовать любой буфер, поскольку работа с CD охраняется ещё одним мьютексом, cd_reserve. Так что если в процессе запуска другое приложение вызовет (скажем) 70.0 на CD, оно подождёт.
    Ушёл к умным, знающим и культурным людям.
  • diamond
    Я в 98SE создавал файл длинной в 265 символов. Создал в Explorer. Удалял в Windows Commander. Проблемы возникли при использовании VoptXP.
    fs_execute читает данные блоками по 0x200 байт. Размер сектора на CD, если не ошибаюсь, 0x800 байт. Размер кластера на HD переменный, но кратен размеру сектора 0x200. Процедура fs_HdExecute.DoRead читает очередной сектор, для чего ей приходится хранить текущий кластер и номер сектора в кластере. Аналогичная процедура для CD должна при каждом 4-м запросе считывать в буфер новый сектор и хранить номер блока в секторе. Буфер лучше использовать по адресу 0x90000, поскольку эта область охраняется вышеупомянутым мьютексом (для другого буфера придётся беспокоиться о сценарии, когда между двумя вызовами .DoRead вызывается, например, функция 70.0 и перезаписывает данные - так что придётся заново считывать этот сектор)
    Хорошо теперь я понял, как сделать.
  • Добавлена функция 70, подфункция 3 - запись данных в существующий файл.
    Кто-нибудь возражает против удаления устаревшей функции 58.3, работающей только с жёсткими дисками? К тому же недокументированной до недавнего времени?
  • diamond
    Если на 100% уверен, что не используется никакой программой, то удаляй.
  • Удалена подфункция 3 функции 58.
    Добавлена подфункция 4 функции 70 - установка размера файла.
    Ушёл к умным, знающим и культурным людям.
  • Не знаю думал ли об этом кто-нибудь, но без файловых дескрипторов и всех вытекающих отсюда последствиях (в моём представлении это буферизация, режимы открытия файли... ) многие вещи становятся не реамыми или решаемыми через заднее место (возможно такая мысль может возникнуть только у программиста до мозга костей приспособленного к виндовс/линукс...)...
    Это я всё кто тому, что это - ,имхо, очень нада. (запятые правильно раставил? а то русский совсем забыл :))
  • Who is online

    Users browsing this forum: No registered users and 11 guests