Board.KolibriOS.org

Не совсем понял вопрос, но я думаю из первых строк кода семидесятой всё должно быть понятно http://websvn.kolibrios.org/filedetails ... fs_lfn.inc

Если это начало любой 70.х, то должно работать одинаково.

Но теперь у меня больше вопрос - в ESI у нас указатель на путь в cp866 в строке 55.
Если по указателю db '/0мусор', то тоже окажется что это не рутдир, т.к EDI=0.

А что не так? Если edi=2, то это utf-16, иначе rootdir.

Точно, ОК.

После ревизии 6845 в одной из моих тестовых программ перестал открываться файл с изображением jpeg. По всей видимости выдается какая-то ошибка фс. Подробнее пока сказать не могу, нет времени на тесты.

Ошибка была найдена в работе программы. Программа пробовала открыть из файла больше байт чем в нем было. Это давало ошибку номер 6, но программа не обращала на это внимания и работала дальше. А после ревизии 6845 перестала работать вообще. Не понятно почему теперь ф. 70 не открывает из файла то что можно из него открыть.

Файловая система FAT? Какой размер файла и какими данными была заполнена структура?

Точно сказать не могу, потому что это файл образа iso, который я тестировал через VirtualBox. Вроде-бы в свойствах файла пишет что какой-то Joliet, хотя я про такую ФС раньше не слышал.
Могу почистить файл iso образа и скинуть для тестов если будет нужно.

Ирония в том, что наш драйвер, который называется iso9660, на самом деле драйвер Joliet, а ISO 9660 он как раз и не поддерживает...

А сейчас что конкретно получается?

Раньше в программе было так:

...
   mov eax,70 ;70-я функция работа с файлами
   mov [run_file_70.Function], 0
   mov [run_file_70.Position], 0
   mov [run_file_70.Flags], 0
   mov [run_file_70.Count], dword size
   m2m [run_file_70.Buffer], [buf]
   mov byte[run_file_70+20], 0
   mov [run_file_70.FileName], file_name
   mov ebx,run_file_70
   int 0x40 ;загружаем файл изображения
   cmp ebx,0xffffffff
   je @f
... открытие файла ...
   @@:
...

где size - размер файла давался с запасом. И оно работало, но давало ошибку о том что файл закончился заранее и не все байты прочитаны.
Для себя я решил проблему обновив алгоритм работы программы. Теперь сначала проверяется размер файла, а потом идет попытка открытия с точным значением размера.
Хотя чисто теоретически оно должно работать и по старому алгоритму. Если пользователь просит считать с файла лишние байты, то по идее должно быть считано все что есть и должна выдаться ошибка 6 (EOF).

Понятно. Исправил документацию.

revision #6880

Теперь нужно проверить есть ли программы которые искали -1 в регистре ebx.
Потому что теперь там будет 0 в случае неудачи.

В принципе, программам должно быть всё равно, файл пустой или его нет.

Это некорректное утверждение.
Ошибка 5 возвращается в случае отсутствия файла у 70.0 и каталога 70.1 (80.0/80.1)?

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