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

mike.dld
Определение свободного места на диске - процесс, вообще говоря, не быстрый. Так, для FAT16 придётся просматривать всю таблицу FAT...
И кроме того, это можно сделать и из приложения.
Mario79

А можешь подробней описать пару случаев?

Например: когда удобней использовать указатель:
1) Имя файла задаётся где-то в командной строке. Тогда разумнее имя файла там и оставить (не копируя его туда-сюда по rep movsb), а просто использовать указатель.
2) При реализации, скажем, библиотечной функции fopen: для выполнения thread-safe необходимо размещать структуру в стеке, а в этом случае явно удобнее использовать структуру фиксированной длины с указателем.
3) Когда в один и тот же файл программа попеременно читает/пишет: в этом случае можно использовать одну структуру для чтения и записи, но тогда придётся регулярно менять параметры; а можно использовать две структуры и указатель нужен, чтобы не дублировать имя файла два раза.
Когда удобней использовать непосредственное задание:
1) Когда, скажем, требуется прочитать настройки из /rd/1/mfar.dat: имя файла фиксировано и его удобней указать сразу после структуры.
2) Когда имя файла встречается в только одной информационной структуре (например, мы только читаем из этого файла), причём появляется оно, скажем, от пользователя - в этом случае можно его вводить прямо в поле после информационной структуры.
all
Давайте всё же определимся. Итак, варианты:
1. Не использовать предложенный синтаксис вообще. В этом случае во многих ситуациях придётся копировать имена туда-сюда (тихо надеясь, что не произойдёт buffer overflow).
2. Не использовать старый синтаксис вообще. В этом случае необходимости в db 0/dd 0 для отличия от старого синтаксиса не нужно, но когда достаточно старого синтаксиса, придётся задействовать лишние 4 байта на указатель.
3. Использовать вариант с db 0 вместо имени для задействования нового варианта. Потери на невыравненность, возникающие в этом случае, ничтожны (с учётом общего времени на работу с файловой системой).
4. Использовать вариант с dd 0 вместо имени для задействования нового варианта. В этом случае тратятся лишние 3 байта по сравнению с предыдущим вариантом. С другой стороны, при инициализации структуры в стеке семейством push этот вариант явно удобнее.
Я предпочитаю вариант 3, но согласен на любой из предложенных. Сложностей в реализации любого из этих вариантов не предвидится (несколько строчек в начале функции file_system_lfn).

diamond
Я согласен с вариантом 3. Я считаю, что все-таки нужно экономить пусть даже 3 байта, если нет необходимости жертвовать размером во имя скорости. Все же файловая система не сравниться в скорости, например, с видеосистемой и поэтому такой потерей производительности можно пренебречь.

Я немного отстал от жизни. О какой структуре идет речь?

я за 3 вариант, потому что обеспечивается совместимость

willow
Совместимость здесь не играет ключевую роль, так как речь идет о 70 функции, а 58 функция, скорее всего не будет подлежать изменениям.

В идеале нужно было бы переписать ВСЕ приложения, использующие функцию 58 на 70-ю.

Heavyiron
Вот только не понятно что делать с теми приложениями, у которых нет (компилирующихся) исходников. (dosbox например)

Ну для них придется оставить 58-ю, или как предлагал Diamond в самом первом посте: модифицировать 58-ю, исправив MFAR, sysxtree... Приложения вроде DosBox-а и игрушек на С судя по всему не пострадают, а лишнего кода со сходной функциональностью в ядре поменьше станет

PS: насколько я понимаю, тогда большинство приложений и править не придется. Поправьте меня, если я ошибаюсь

Вариант 3 внедрён в ядро. Документация уже обновлена.
Да, кстати, последняя ревизия ядра выложена на http://diamondz.land.ru/kernel.mnt и будет регулярно (в меру моих возможностей) обновляться. Предупреждаю, что это не более чем текущая версия, которая не подвергалась тщательному тестированию и может содержать недавно добавленные ошибки!
Heavyiron
dosbox, к сожалению, ориентируется на то, что при чтении папки возвращаются данные как они есть в FAT. Так что не всё так просто...

В идеале нужно было бы переписать ВСЕ приложения, использующие функцию 58 на 70-ю.

Совершенно согласен. После чего удалить 58-ю функцию нафиг.
halyavin
Ясно что - пытаться перекомпилировать
Ещё один вариант - попробовать прямо пропатчить бинарники...

Функция 70, подфункция 5 - получение информации о файле (структура БДВК, за исключением имени файла)
Функция 70, подфункция 6 - установка атрибутов файла (структура БДВК, за исключением имени и размера)
Подфункции 3 и 4 зарезервированы соответственно под запись в существующий файл и установку конца файла (мне показалось логичным сгруппировать вместе подфункции, изменяющие содержимое файла).
Никто не против удаления подфункций 12, 13, 14 функции 58? Их всех заменяет 70.5, я не знаю программ, использующих эти подфункции, кроме того, они не поддерживаются для дискет.
На очереди подфункция 7 - запуск файла с длинным именем. Тут есть две концептуальные трудности:
1. Если приложение использует путь к себе (последнее поле заголовка), то ему могут не понравиться длинные имена в пути. В сущности, это вопрос к mike.dld, может ли tinypad нормально это обработать? Других приложений, использующих это, вроде бы ещё нет...
2. Под имя процесса, возвращаемое функцией 9, выделено только 8+3 символов. Причём на это ориентируются такие существенные для системы приложения, как cpu и @panel. И что с этим делать?

12 нужно оставить, так как, вероятно, все же есть программы, ее использующие

Зачем старым программам её использовать? Функция 58.0 (чтения) возвращает прямо размер. Так что я не вижу причин, по которым существующим программам была бы нужна 58.12. (И не знаю программ, использующих её).