Board.KolibriOS.org

Текущая реализация файловой системы имеет следующие ограничения:
1. Поддержка только FAT.
2. Поддержка только имен файлов в формате 8.3.
Есть одно исключение - при чтении директории длинные имена можно добыть. Но, во-первых, это не является заслугой ядра, а во-вторых, обращаться к файловой системе по этим именам все равно нельзя.
3. Отсутствие нормальной работы с директориями - можно только читать их как файлы. С этим еще можно работать, пока поддерживается только FAT, хотя и несколько неудобно, но в дальнейшем...
О пункте 1 речь пока не идет. Я собираюсь сделать нормальную работу с длинными именами файлов и, потом, с каталогами, но:
для работы с файловой системой используется 58-я функция. (Все прочие всегда можно объявить устаревшими.) Формально в документации примеры путей имеют вид "/hd/1/file.ext". Но ядро понимает также имена типа "/hd/1/FILE EXT" (4 пробела) (и даже "/hd/1/FILENAMEEXT" как "/hd/1/filename.ext"). Поэтому для длинных имен придется делать одно из:
1) Отказаться от обратной совместимости, поправить mfar, sysxtree (кстати, есть еще программы, использующие это?) (надеюсь, я могу заниматься такими модификациями?)
2) Завести новую сисфункцию типа "расширенная работа с файловой системой"
3) Завести дополнительные подфункции в 58-й функции типа 0x100 - read, 0x101 - write и т.д.
Ваше мнение, коллеги?
P.S. Я предпочитаю забить на обратную совместимость.

_________________
Ушёл к умным, знающим и культурным людям.

diamond
1) Нельзя отказываться от обратной совместимости совсем. И программ использующих 58 функцию больше чем эти 2, которые ты перечислил. Мы в обязательном порядке потеряем все игры собранные на Cи.
2) Вот сделай это, только не трогая прежних процедур. Сделай пока параллельную работу обоих подсистем.
3) А кто мешает.
Я все же за то чтобы оставить обратную совместимость.

Я тоже за введение нового при поддержке старого.

Mario79
Этой недокументированной особенностью 58 функции пользуется не так много программ.

halyavin
Да делайте блин что хотите.
Один хер мое мнение в лучшем случае уже, похоже, никого не интересует.

Марат, опять начинаешь? -- mike.dld
Миша не изображай из себя бога или суперцензора! Я в твои посты не залажу, имей совесть, если она у тебя есть. -- Администратор Mario79

Так если ввести новую системную функцию,то можно будет читать файлы через неё.А 58 функцию оставить как есть,зачем её переписывать.В результате будет улучщена работа с файловой системой при совместимомти со старыми программами.

Мне совсем не хочется,чтобы игрушки которые ущё вчера работали,сегодня бы уже не работали.

Игрушки, которые ещё вчера работали, будут продолжать работать. Пути типа "/hd/1/dir1.d/file1.ext" будут продолжать работать точно так же. Возможность чтения типа "FILENAMEEXT" недокументирована и работает только в силу особенностей кода ядра. Этой недокументированной возможностью, как уже сказал halyavin, пользуются только небольшое количество программ, я знаю только mfar/sysxtree.
Это чтобы прояснить ситуацию. А вообще если говорите, что лучше оставить совместимость, - прекрасно, пусть будет совместимость (даже на уровне недокументированных функций). Тогда остаются варианты 2 и 3.
А кстати, эти особенности присутствуют из-за того, что вся работа завязана на FAT. Думаете, человек, который будет писать поддержку ext*fs или NTFS, захочет (и вообще сможет) эмулировать такие эффекты?

_________________
Ушёл к умным, знающим и культурным людям.

diamond
Я же высказал свое мнение. Если ты считаешь, что, так как предлагаешь ты:
1) Лучше
2) Надежней
3) Ты согласен получать пинки и вовремя отвечать на них лично.
То делай, что задумал.

Вообще у меня уже у самого вызревает идея изменения обработки дисковых функций, но не в том ключе, который предлагаешь ты.
Если будет желание узнать, мыль мне mario79[dog]bk[dot]ru и распиши подробнее, что хочешь сделать. Потому что нужно согласовывать подобные действия, чтобы не получить два противоположных результата.

diamond
Я как-то не думал, что считывание папки как файла является недокументированной функцией. Я почему-то думал, что это обычное дело.
Извиняюсь за оффтоп. SYSXTREE не запускает приложения, если в строке пути присутствует точка.

Подводя итог: народу нравится обратная совместимость. Хорошо, на том и порешим. Пока нет поддержки других файловых систем, это будет работать. Я собираюсь ввести новые подфункции 58-й функции, начиная с 0x100 (для удобства) - чтение/запись/... с учётом длинных имён.
Mario79
Считывание папки как файла в сегодняшней Kolibri - вещь, похоже, документированная (правда, с определением документированности есть некоторые проблемы). Я просто просматриваю в перспективе добавление ext*fs и NTFS, а там структура директорий совершенно другая.

_________________
Ушёл к умным, знающим и культурным людям.

diamond
Ну, в ISO9660 структура тоже несколько другая, а я рассматриваю возможность добавления в ядро исходников, которыми со мной любезно поделился заграничный товарищ Dex.
Давай тогда вырабатывай единый стандарт, в который будут преобразовываться данные на выходе для приложения.
Отсутствие стандарта на многие вещи самая большая проблема для Колибри.

Добавил чтение с длинными именами файлов - подфункция 0x100 функции 58 (описание входит в мою документацию, online-версия http://shade.msu.ru/~msu-se/klbr_doc/58100.htm)

_________________
Ушёл к умным, знающим и культурным людям.

diamond
А может стоит перенести реализацию новых подфункций в 70 функцию? Я как раз для этого ее зарезервировал.
Впрочем, дело твое.

Mario79
Да мне без разницы. Это как народ скажет...

_________________
Ушёл к умным, знающим и культурным людям.

diamond
Психологически проще.