Сначала я хочу различить две очень разные вещи:
- Как реализация проприетарного
convert.exe в Windows обеспечивает преобразование файловой системы на месте между FAT32 и NTFS.
- Как, в общем, можно подойти к проблеме преобразования между двумя файловыми системами на месте, не имея в 2 раза необходимого дискового пространства, или совместимых метаданных между двумя файловыми системами, или других подобных тонкостей, которые могут сделать проблему тривиальной
Во-первых, мы в основном от власти Microsoft выпустить эту информацию, потому что любой, кто получает доступ к источнику Windows, должен подписать NDA. Он будет выпущен только в случае одобрения юридической командой Microsoft. Конечно, возможно кто-то, читающий этот вопрос, получил нелегальную копию просочившегося исходного кода Windows и выяснил это из кода, но это законная серая область.
Поэтому я не буду пытаться дать ответ на первый вопрос, потому что у меня нет ответа.
Однако я отвечу на второй вопрос.
В истории файловых систем было много случаев, когда мы хотели перейти с одной файловой системы на другую без очистки ОС, переустановки или использования второго диска. Назвать несколько:
- В 2017 году каждый , кто обновлял устройство Apple iOS до iOS 10.3, получал обновление файловой системы с HFS+ до APFS на встроенном NAND своего iDevice.
- В течение многих лет btrfs поддерживал обновление файловой системы на месте с ext4 до btrfs с помощью инструмента btrfs-convert .
Программа с открытым исходным кодом fstransform предназначена для преобразования между многими различными файловыми системами (с некоторыми оговорками и ограничениями) - и она включает в себя многие / наиболее распространенные файловые системы Linux, а также, что впечатляюще, NTFS! Тем не менее, он еще не поддерживает FAT32, несмотря на поддержку множества других файловых систем.
Чтение его кода C++ предоставит вам наиболее подробные технические знания, которые вам требуются, об общих алгоритмах преобразования разнородных файловых систем, даже если совместимость или совместимость не планировались и не разрабатывались авторами исходной файловой системы (ни исходной, ни целевой файловой системой). !).
Общий процесс, в общих чертах, будет выглядеть примерно так:
- Обойти дерево файлов / каталогов текущей файловой системы; и в новом обычном файле в существующей файловой системе создайте специфичную для FS файловую таблицу (список файлов, каталогов, символических ссылок, разрешений и т. д.) на основе списка файлов текущей файловой системы, но в формате новой файловой системы. ,
- Переформатируйте структуры данных и метаданные на месте старой файловой системы в терминах структур данных новой файловой системы и обновите указатели (на блоки и смещения логического диска, в зависимости от случая) в новой файловой таблице, чтобы они указывали на пересчитанный файл. Блоки / directory / Разрешения (использование общих понятий, таких как "inodes" или "streams", в зависимости от того, из какой файловой системы вы преобразуете / в это будет зависеть).
- В самом конце процесса деструктивно перезаписать метаданные исходной файловой системы (которая идентифицирует файловую систему как старый тип файловой системы с использованием магических чисел и т.д.) С метаданными новой файловой системы и создать соответствующие карты, которые указывают на "суперблок", "MFT" или любые другие специфичные для файловой системы структуры данных требуются для инициализации файловой системы.
- Обновите глобальную таблицу разделов диска (например, формат MSDOS или формат GPT), обновив магическое число, которое указывает на тип файловой системы, содержащейся в разделе, при необходимости (примечание: некоторые файловые системы используют один и тот же магический номер, потому что AFAIK это только 16- номер бита, так что есть только 65 535 возможностей. И некоторые драйверы файловой системы достаточно умны, чтобы игнорировать магическое число и "исследовать" фактические структуры данных файловой системы, чтобы определить, содержит ли этот раздел экземпляр данной файловой системы.)
Стоит отметить, что, по крайней мере, последние два шага не являются атомарными ; это означает, что обычные гарантии атомарности журнализированной файловой системы (например, NTFS, reiserfs, XFS, zfs и т. д.) недоступны. Если система дает сбой, выключается или даже если во время этого процесса происходит сбой или зависание программы пользовательского пространства, выполняющей преобразование, файловой системе потребуется эксперт по восстановлению данных, чтобы вернуть ваши данные или восстановить работоспособность файловой системы (старой или новой). Во время этих "деструктивных" операций базовый носитель данных выполняет деструктивную перезапись критических данных способом, который не резервируется журналом файловой системы, из-за процесса, по сути, обходящего журнал старой файловой системы (чтобы перейти от одного FS другому, вы не можете сказать старой файловой системе "безопасно убить себя", перезаписывая ее основные метаданные чем-то другим, о чем она не знает).
В отличие от этого, запрос файловой системы, которая выполняет ведение журнала данных для обычной записи, на самом деле является атомарным: либо полная запись завершена, либо не завершена вообще (неполная частичная запись в область журнала может быть отменена, если в процессе записи происходит сбой системы, что и делают программы fsck или chkdsk при загрузке после того, как BSOD вашей системы или паника ядра.)
Выполнение преобразования FS на месте довольно рискованно - оно примерно так же рискованно, как и флэш-память BIOS (особенно на мобильных устройствах, где вы можете навсегда заблокировать ваше устройство, имея не загружаемую ОС), потому что безопасность многих операций не гарантируется, и на это уходит много времени, так что есть большая вероятность того, что пользователь подумает, что ОС зависла и выключил и выключил ее во время преобразования, или если устройство с батарейным питанием разрядилось.
Для более глубокого понимания того, как это можно сделать более безопасным, благодаря знанию сотрудничества двух файловых систем, предназначенных для преобразования между двумя (что, как я понимаю, в случае преобразования HFS+ в APFS на iOS), это увлекательное talk использует криминалистический подход к выяснению того, что, черт возьми, происходит с APFS. Он напрямую не решает проблему конверсии, но некоторые сведения о конверсии могут быть получены из предоставленной информации.
Все это говорит о том, что на ваш точный первоначальный вопрос может никогда не найти окончательного ответа, но я думаю, что предоставление большого количества знаний об общем процессе преобразования FS на месте должно дать вам достаточно подсказок, чтобы де-мистифицировать то, что вероятно быть процессом для convert.exe .
Кстати, я изначально думал: «О, здорово, ReactOS уже внедрила этот инструмент, и мы можем просто просмотреть исходный код!"- Нет. Они не реализовали convert.exe в открытом доступе на ReactOS. Если он вообще используется любым пользователем в своей системе, он должен выполнять проприетарный двоичный файл MS Windows. В противном случае, я думаю, они просто не предоставляют эту утилиту в ReactOS.
