Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Oct 19, 2021 11:21 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 259 posts ]  Go to page Previous 1 2 3 4 5 618 Next
Author Message
 Post subject:
PostPosted: Tue May 30, 2006 10:16 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1600
Написана функция 70, подфункция 2 - создание/перезапись файла с поддержкой длинных имён.
По поводу нового синтаксиса - иногда бывает полезным и существующий вариант. Например, когда имя файла фиксировано, скажем, '/rd/1/char.mt', его удобнее писать сразу после структуры, не расходуя лишние 4 байта на указатель.

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


Top
   
 Post subject:
PostPosted: Tue May 30, 2006 12:31 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 693
Если есть возможность определения размера существующего файла и свободного места на диске, может не переписывать файл новым, если для него всё равно не хватит места? Чтобы зря файл не портить...


Top
   
 Post subject:
PostPosted: Wed May 31, 2006 4:25 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1600
mike.dld
Определение свободного места на диске - процесс, вообще говоря, не быстрый. Так, для FAT16 придётся просматривать всю таблицу FAT...
И кроме того, это можно сделать и из приложения.
Mario79
Quote:
А можешь подробней описать пару случаев?

Например: когда удобней использовать указатель:
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).

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


Top
   
 Post subject:
PostPosted: Wed May 31, 2006 7:13 pm 
diamond
Я согласен с вариантом 3. Я считаю, что все-таки нужно экономить пусть даже 3 байта, если нет необходимости жертвовать размером во имя скорости. Все же файловая система не сравниться в скорости, например, с видеосистемой и поэтому такой потерей производительности можно пренебречь.


Top
   
 Post subject:
PostPosted: Wed May 31, 2006 9:50 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Я немного отстал от жизни. О какой структуре идет речь?


Top
   
 Post subject:
PostPosted: Thu Jun 01, 2006 10:32 am 
Offline

Joined: Wed May 25, 2005 8:52 am
Posts: 147
я за 3 вариант, потому что обеспечивается совместимость


Top
   
 Post subject:
PostPosted: Thu Jun 01, 2006 7:27 pm 
willow
Совместимость здесь не играет ключевую роль, так как речь идет о 70 функции, а 58 функция, скорее всего не будет подлежать изменениям.


Top
   
 Post subject:
PostPosted: Thu Jun 01, 2006 10:19 pm 
Offline
User avatar

Joined: Fri Jan 27, 2006 3:06 pm
Posts: 1073
В идеале нужно было бы переписать ВСЕ приложения, использующие функцию 58 на 70-ю.


Top
   
 Post subject:
PostPosted: Fri Jun 02, 2006 7:39 am 
Heavyiron
Вот только не понятно что делать с теми приложениями, у которых нет (компилирующихся) исходников. (dosbox например)


Top
   
 Post subject:
PostPosted: Fri Jun 02, 2006 2:10 pm 
Offline
User avatar

Joined: Fri Jan 27, 2006 3:06 pm
Posts: 1073
Ну для них придется оставить 58-ю, или как предлагал Diamond в самом первом посте: модифицировать 58-ю, исправив MFAR, sysxtree... Приложения вроде DosBox-а и игрушек на С судя по всему не пострадают, а лишнего кода со сходной функциональностью в ядре поменьше станет


Top
   
 Post subject:
PostPosted: Fri Jun 02, 2006 2:12 pm 
Offline
User avatar

Joined: Fri Jan 27, 2006 3:06 pm
Posts: 1073
PS: насколько я понимаю, тогда большинство приложений и править не придется. Поправьте меня, если я ошибаюсь


Top
   
 Post subject:
PostPosted: Fri Jun 02, 2006 5:45 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1600
Вариант 3 внедрён в ядро. Документация уже обновлена.
Да, кстати, последняя ревизия ядра выложена на http://diamondz.land.ru/kernel.mnt и будет регулярно (в меру моих возможностей) обновляться. Предупреждаю, что это не более чем текущая версия, которая не подвергалась тщательному тестированию и может содержать недавно добавленные ошибки!
Heavyiron
dosbox, к сожалению, ориентируется на то, что при чтении папки возвращаются данные как они есть в FAT. Так что не всё так просто...
Quote:
В идеале нужно было бы переписать ВСЕ приложения, использующие функцию 58 на 70-ю.

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

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


Top
   
 Post subject:
PostPosted: Thu Jun 15, 2006 4:24 pm 
Offline
Kernel Developer
User avatar

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

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


Top
   
 Post subject:
PostPosted: Thu Jun 15, 2006 4:34 pm 
Offline

Joined: Wed May 25, 2005 8:52 am
Posts: 147
12 нужно оставить, так как, вероятно, все же есть программы, ее использующие


Top
   
 Post subject:
PostPosted: Thu Jun 15, 2006 4:38 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1600
Зачем старым программам её использовать? Функция 58.0 (чтения) возвращает прямо размер. Так что я не вижу причин, по которым существующим программам была бы нужна 58.12. (И не знаю программ, использующих её).


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 259 posts ]  Go to page Previous 1 2 3 4 5 618 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited