NTFS

Drive subsystem, filesystem drivers
  • Запись в пустые папки
  • Красавчик! :D потестим :)
  • Создание папок
  • Теперь не должно быть проблем из-за переименования... только я так и не понял, как оно у вас делается.
  • Pathoswithin wrote:Теперь не должно быть проблем из-за переименования... только я так и не понял, как оно у вас делается.
    Посредством копирования файла с новым именем, и удалением варианта файла с предыдущим именем
    to infinity and beyond
  • жуть
  • Хотя, возможно, можно переименовать файл через ф70.6 Попробую позже
    to infinity and beyond
  • звучит обнадёживающе
  • Я позапускала немного. Код нормально создаёт файлы и подпапки в корневой папке, но в прочих папках возникают проблемы: на пустом разделе я создаю пустую папку "folder" в корне, копирую файл в папку "folder". Винда видит файл в папке "folder", но виндовый chkdsk сообщает об ошибке "Неправильный элемент NOTIFY3.PNG в индексе $I30 файла 35."
    Сделаем мир лучше!
  • chkdsk это отдельная тема. Например, у файловой таблицы есть свой битмап для поиска пустых записей. Но в каждой записи тоже есть флаг её использования. При удалении записи достаточно очистить бит битмапа. Но если после этого запустить chkdsk, то он найдёт "потерянные файлы". При расширении таблицы я не делаю обнуления новых записей - результат аналогичный (после форматирования раздела очисткой оглавления всплывают прошлые файлы).

    Там только в соседней теме ntfs.inc поновее.
  • Опасно оставлять систему в несогласованном состоянии. Захочет виндовый драйвер создать новую файловую запись, выделит из битмапа, увидит, что в записи помечено, что она используется, и из лучших побуждений восстановит файл. Даже если ты тестировал, что драйвер этого не делает, - нет никакой гарантии, что алгоритм выделения в тестах выбирал именно эту запись, и что во всех существующих версиях винды от NT3.1 до Windows 10 драйвер ведёт себя одинаково.

    У меня ещё такая просьба. Можешь создать структуры, используемые на диске в NTFS, и писать не непосредственные смещения вроде [esi+18h], а что-то разумное вроде [esi+some_disk_struct.some_field]? Хотя бы в новом коде. Невозможно же читать

    Code: Select all

            mov     esi, [ebp+NTFS.frs_buffer]  ; mftRecord
            mov     edx, [esi+18h]
            add     edx, ecx
            cmp     [esi+1ch], edx
    
    Сделаем мир лучше!
  • Нет, я такого не тестировал, там ещё куча работы (около половины). Знаю что виндовый драйвер ничего сам не исправляет, а только помечает раздел как грязный. chkdsk больше любит удалять, восстановит только если всё идеально сойдётся (сразу после форматирования). Сейчас я рад тому, что explorer читает.

    Ого! Ты представляешь себе масштаб этой работы? Посмотри после метки .mftRecord: какая там движуха. Это надо пол документации в код перенести. А документация неофициальная, названий у полей нет. Некоторые структуры используются в составе других структур, при этом изредка немного отличаются. Самое главное, пожалуй, что не всегда известны реальные размеры полей. Обрати внимание, я часто использую минимальный размер (byte), даже если знаю, что поле больше.
    Например, после того, как в колибри всё заработало, я много часов смотрел в hex редактор, чтобы понять, чем не доволен explorer. В документации написано, что поле "File reference to the parent directory" (в индексе каталога называется "MFT File Reference of the parent") имеет размер 8 байт. Я быстро заметил, что последние 2 байта копируют первые, выходит само поле 6 байт. Или может 4, а пятый и шестой под что-то другое. Более того, подобное поле каталога "MFT Reference of the file" в последних двух байтах содержит "1". Я понятия не имею, что это значит, но если там будет что-то другое, то файл повреждён. В общем, я не уверен что смогу применить в ntfs понятие "что-то разумное".
    Разве что комментариев побольше написать... Но без документации всё равно ничего понятно не будет. На правах троллинга: по сути в документации смещения вместо названий.
  • Pathoswithin wrote:Знаю что виндовый драйвер ничего сам не исправляет, а только помечает раздел как грязный.
    В какой системе? Википедия говорит, что "Windows Vista implemented Transactional NTFS, NTFS symbolic links, partition shrinking and self-healing". Я, впрочем, не знаю, что конкретно они имеют в виду под self-healing.
    Pathoswithin wrote:Ого! Ты представляешь себе масштаб этой работы?
    Проставлять названия полей в ~2000 строках, оставшихся от diamond'а, и правда масштабно. Но в новом коде, когда ты пишешь [edi+16], ты же держишь в уме, что edi указывает на MFT record, а 16 - вполне конкретное поле в этой MFT record? Если используешь byte - можешь и дальше использовать byte. Если размер полей неизвестен - хотя бы константы заведи

    Code: Select all

    some_struct.some_field_1 = 0
    some_struct.some_field_2 = 4
    some_struct.some_field_3 = 14h
    
    Pathoswithin wrote:А документация неофициальная, названий у полей нет.
    Возьми, например, из ядра Linux. Или из ntfs-3g - там, кажется, примерно то же самое, но немного больше по размеру.
    Pathoswithin wrote:В документации написано, что поле "File reference to the parent directory" (в индексе каталога называется "MFT File Reference of the parent") имеет размер 8 байт. Я быстро заметил, что последние 2 байта копируют первые, выходит само поле 6 байт. Или может 4, а пятый и шестой под что-то другое. Более того, подобное поле каталога "MFT Reference of the file" в последних двух байтах содержит "1". Я понятия не имею, что это значит, но если там будет что-то другое, то файл повреждён.
    https://technet.microsoft.com/ru-ru/bb470211
    Теперь понятно, что chkdsk не нравится при создании файлов не в корневой папке. Последние 2 байта - это "circularly reused sequence number that is set at the time the MFT segment reference was valid". Для системных записей, включая корневую папку, которые никогда не удаляются, там действительно копия номера записи - кроме $MFT с номером 0, где оно заменено на 1, - а для прочих записей оно инициализируется единицей при первом создании записи и увеличивается каждый раз при переиспользовании, при переполнении снова сбрасывается в 1. Чтобы в случае чего можно было отследить, что вот эта ссылка на MFT record 42 создавалась давно, и с тех пор MFT record 42 была удалена и переиспользована, а ссылка битая.
    Сделаем мир лучше!
  • CleverMouse wrote:Возьми, например, из ядра Linux. Или из ntfs-3g - там, кажется, примерно то же самое, но немного больше по размеру.
    Также названия полей можно заимствовать из прородителя - HPFS. (правда, там очень мало можно заимствовать)
  • Who is online

    Users browsing this forum: No registered users and 5 guests