Есть проблема с чтением NTFS файлов и папок. Иногда поток зависает с загрузкой 100%. Доступ к диску блокируется намертво. У многих файлов при просмотре вместо правильного содержимого выдается набор каких-то структур с тегами ICS1. Атрибуты у файлов обычные без сжатия и шифрования.

Похоже что баг связан с дефрагом. Пострадали файлы которые давно не изменялись. Если их перекопировать то они читаются нормально. Теперь можно слушать музыку с NTFS. Хорошая работа.

diamond
NTFS работает без пролем. Хорошая работа!
Остается еще доделать ISO9660, сделать поддержку Ext2 и UDF (вроде так называтся еще одна файловая система для CD и DVD). И систему можно считать устоявшейся.

Спасибо.
Мёртвая блокировка доступа к диску даже после прибивания приложения, работавшего с диском, - это проблема не в коде NTFS. Глюки с чтением некоторых файлов и папок бывают (сам видел, уже после заливания на svn) и будут исправляться.

Глюки с зависанием при чтении исправлены. Наиболее вероятное объяснение появления структур ICS1 (которые не имеют отношения к структуре NTFS) - наличие именованных NTFS-потоков в файле. Я, кстати, понятия не имею, как можно проверить (без просмотра диска на физическом уровне) наличие нескольких потоков на пользовательском уровне. На WinAPI это делается через FindFirstStreamW/FindNextStreamW, но эти функции появились только в Win2003 Server. Ревизия 273 работает корректно на файлах с несколькими потоками (читая только главный).

Добавлена функция 70, подфункция 9 - создание папки. (Естественно, не работает для NTFS-томов).

В последнее время все чаще возникает вопрос, почему в эмуляторах не удается сохранить РАМ-диск на дискету. В vmware доступ к /fd/1/ есть. Kfar-ом попробовал удалить и скопировать несколько файлов - все работает, а при вызове функции 16/1 возвращается ошибка В qemu не удалось даже получить доступ к /fd/1/ из kfar-a

На сколько я знаю qemu использует hardware-level от bochs, а разработчики bochs в упор не хотят исправлять багов в своей эмуляции дискеты (хотя я им детально писал в чем дело). Точнее пишут, что баги исправлены, хотя на самом деле все работает по-прежнему неправильно.

Похоже что ф.70.5 виснет если ей передать несуществующий путь на CD. Если запустить такой файл через run придётся перегружать ядро, загрузчик определяет через 70.5 размер файла.
По этой причине andrew_programmer не смог запустить Doom с CD

Исправлено. Ревизия 364.

Выяснил интересные вещи.

Если включить поддержку DMA, то фалы в KFAR копируются правильно.Так как на моём компьютере DMA код работает некоректно, то копируемые файлы естественно портятся.Но факт тот, что копирование происходи успешно и без глюков.

Если выключить поддржку DMA( тоесть работать будет через PIO), то при копировании файллов размером больнше нескольких сотен килоюбайт происходит ошибка в работе кода и файл не копируется.Я попробовал скопировать файл из некоторого каталога жёсткого диска в корень жёсткого диска.Файл не скопировался, а вот в корне диска появились какие-то странные файлы.У этих файлов вместо букв в названии символы(рожицы и т.д.).И после этого перестала грузиться винда(пишу из линукса).

Также я проводил тестирования разных версий FASM-ов(очень старые версии и самые новые).Я компилировал ими тестовую программу, которая после компиляции подвешивает Тинипад.Разные фасмы одинаково подвешивали Тинипад.Я так и немогу понять в чём дело - в FASM-е или в ядре.

Нашел ошибку в работе драйвера файловой системы: при просмотре определённого каталога его содержимое отображается, как совокупность бессмысленных файлов и каталогов. В тоже время этот же самый каталог в досе и винде отображается корректно.

Maxis
Дай я угадаю - папка находится на диске с файловой системой NTFS?
Тогда нет ничего удивительного - NTFS поддержан только на чтение и не полностью, так как это пока незаконченный драйвер.

Mario79
Нет. Папка находится на FAT32 разделе.